rousso.eu » Computing

ECDIS software

rousso — Mon, 17 Mar 2008 10:20:42 +0000

I am working on two ECDIS projects in parallel. Both have to do with monitoring sea traffic.

As some details of the projects are confidential, I am not currently able to release any details on the projects themselves. But I can talk about my work in those two projects.

Project A:

The goal is to create a system that will help track ships that are involved in, or responsible for different types of events that can happen in the seas. For instance: an oil spill is located and reported somewhere. Authorities need to identify the vessels, suspect for causing the environmental damage.

The project approaches the problem by creating a system that will allow for sea traffic monitoring and then, correlating that information with earth observation (EO) data to produce a list of suspect vessels. Vessels are ranked by certain qualitative, quantitative and spatial criteria to help the user make the final decisions and identify the offending vessel using the hints provided by the system along with his/her experience and best knowledge.

What I am building for this project is a custom ECDIS system that implements all the functionality required for this application.

Sea traffic is monitored using a network of AIS receivers. AIS messages are temporarily recorded in local databases and transmitted in real time to a central database through web services over a VPN.

The ECDIS software I am building is using AIS signals to mark the positions of different vessels at specific points in time. It also provides a mechanism for importing and recoding vector data that come form EO sources (processed satellite imagery). EO data are used to identify event locations and possibly other detected targets in the area of the event during data capture.

The concept of the software developed is described below. I will post some screen-shots or a screen-cast when possible to support the description below:

The application window is divided vertically into two panes. The main pane (on the left) is the map pane where the ENC is displayed. The second narrower pane on the right is used for context sensitive information display. Both panes are tabbed for better information and functionality grouping. Application commands are available through main and context menus and toolbars.

Below the ENC pane there is a set of playback controls much similar to those you see in video players: a Play/Pause button, a timeline you can scroll, a playback speed selector etc.

All data recorded in the system (be them AIS messages, EO data or Events) are tied to a specific point in time and space.

The concept is that while the system’s database maintains historical sea traffic data for long periods of time, the user only needs to focus on a specific subset of those data related to a particular event. To enable this approach the application allows the user to select one of the recorded events to focus on. Focusing on an event implicitly means filtering AIS and EO data to a specific point in time and space. More accurately: around a specific point in time and space. This way the system loads only relevant data from the database which makes processing faster and consumes less system resources. Selection of the timeframe and area is made either implicitly and explicitly by the user during the selection of the event under investigation.

So keep in mind two concepts here:

the “investigated time-frame” which is essentially a period determined by a staring date/time and a length (duration)
and the “investigated area” determined by the central location of the event and a range in nautical miles around it.

All data that fall into the selected time and space are loaded into in memory data sets. But not all those data are concurrently displayed in the ENC pane. The AIS and EO data displayed in the ENC pane at any given time is a subset of the loaded data and is determined by:

the “focus time”
the length of the “visible time-frame”
and the view-port (which is identified by its center coordinates and range)

The “focus time” is equivalent to the playback position in a video player. As the user scrolls the timeline control to the left or right, the focus time changes.

The length of the “visible time-frame” refers to the time span before focus time during which all recorded signals should be visualized. For instance if the visible time-frame is set to 1 hour then the track behind a vessel’s “current” position will be displayed for the last hour (“current” being determined by “focus-time”).

The “view-port” is nothing more that the visible area of the ENC and is defined by means of panning and zooming the map.

Probably you are already getting the “big picture“: A system that will playback what happened around an event (i.e. an oil spill) and allow you to watch it like you would watch a video. What you see is what you would see if you were flying with a plane over the event at the selected time, only mapped in ENC, loaded with useful information and of course: interactive.

During playback, you can move around the map by zooming and panning, change the playback speed and generally interact fully with the application (all functionality remains available).

By pointing your mouse to a vessel’s latest signal or track you can see relevant information on the right pane of the application. Information available for each vessel includes all category 5 AIS message fields (ship static and voyage information), all fields of categories 1, 2 & 3 of AIS messages (position reports) and derived information based on algorithms and ranking databases, that help classify the ship and rank the probability of it being the offending vessel.

At the time of writing this project is in its final stages. It has been demonstrated to the customer and given their satisfaction it is pending some further development and optimizations before it is officially presented and delivered.

Project B:

Project B is an entirely independent project from Project A. Nevertheless, it is so relevant in context, that it is being developed in parallel. Actually so far I did not see a need to even branch the first project. Minor behavioral differences are handled very effectively through configuration files.

The goal of this project is to use AIS, VTS radar and EO data to identify certain types of vessels in the context of naval security.

AIS, VTS and EO data are correlated with data fusion algorithms and the results are again ranked by risk level.

My work in this project involves the creation of the visualization console. Data acquisition and fusion is handled by other project parties and the results of their work is just input data for my application.

The main difference from Project A is that this time, the software must be used mainly for near real-time monitoring. Playback is just a useful feature.

This project uses more sophisticated data sets and also includes estimated data. There are also considerable differences in data formats. All these had being handled properly during the design phase of the software and provisions where made so that it can read a wider variety of different data sources.

This project is also approaching its demonstration phase.

Technologies used in both projects include:

Apart from the above technologies these projects required extensive understanding of ECDIS, ENCs, AIS, VTS and EO related literature and of course engineering know-how in both software and earth sciences.

Both systems are being developed using Microsoft Visual Studio 2005 and C#.

Can’t change access modifiers when inheriting from Generic Types.

rousso — Thu, 21 Feb 2008 15:26:32 +0000

Well I might be silly, but I had not run-up to this one yet. Until just now:

You cannot change the accessibility level of a class member by means of hiding when inheriting from a generic type.

Consider this example. A simple console application using two classes: MyList inherits from List and My2ndList inherits from MyList. Generic type List has a public method named Add that is not declared as virtual.

My intention was to completely hide the base implementation of the Add method in my derived class. In other words, let’s assume that I want MyList class to not expose an Add method. What one would normally do in this case, would be to hide the method by using the new modifier and changing its access modifier from public to private like I tried to do in line 32 of the code snippet that follows.

Well. Guess what. This does not work if you are inheriting from a Generic Type. Try the code bellow then try to play around with the access modifiers in lines 32 and 47. Although I would normally assume that the code bellow would not even compile, it does!

using System;
using System.Collections.Generic;
using System.Text;

namespace TestGenerics
{
    class Program
    {
        static void Main(string[] args)
        {
            MyList myList = new MyList();
            myList.Add(1);
            myList.Add(2);
            myList.Add(3);

            myList.Print();

            Console.WriteLine("Now the 2nd List");

            My2ndList my2ndList = new My2ndList();
            my2ndList.Add(1);
            my2ndList.Add(2);
            my2ndList.Add(3);

            my2ndList.Print();
        }

    }

    public class MyList : List
    {
        new private void Add(int item)
        {
            item *= 10;
            base.Add(item);
        }

        public void Print()
        {
            foreach (int item in this)
                Console.WriteLine(item.ToString());
        }
    }

    public class My2ndList : MyList
    {
        new private void Add(int item)
        {
            item *= 100;
            base.Add(item);
        }
    }
}

So why am I posting about this?

Well… I didn’t come across any comments on the subject on the Internet for the little I looked around and I thought it was an interesting thing to talk about.

If you know of any links discussing the subject and explaining the internals of the compiler or generics implementation in C#, then by all means please do leave a comment to this post.

If you’d like to copy paste the code above then go get it here.

Information aesthetics

rousso — Thu, 19 Jul 2007 08:57:46 +0000

Only today I discovered this site on data visualization and visual design, which I found extremely interesting:

information aesthetics (http://infosthetics.com/)

I subscribed to its RSS feed and I might also add it somewhere here in my site too.

About Twitter

rousso — Fri, 22 Jun 2007 10:09:51 +0000

I found out about Twitter on a friend’s blog a couple of months ago. Today I was looking for an alternative and I bumped on lots of posts debating Twitter, its value and its alternatives. So I am posting some links to them along with my personal opinion on the matter.

Here are the links:

Goodbye Twitter by Leo Laporte
Twitter vs. Jaiku Battle by Rafe Needleman
RIP Twitter by Mat Balez (with lots of nice comments)
Jaiku.com (a Twitter alternative)

My personal opinion is this: Twitter is just another effort to something new. I can’t really go on predictions, because things change on the web and they do change fast. So I am in, but wait and see…

I was looking for an alternative to Twitter today, because, though I do not use it that much, 9 out of 10 times I have tried to use Twitter, some, if not all of its features, are down for maintenance… IM does not really work most of the times. I am using AIM because neither Windows Live Messenger is supported, nor can I setup my own-domain-GTalk (as I need to add DNS SRV records which my DNS provider does not support). Even the web interface which should be mostly available was down again today. Posting by SMS is a nice alternative but still silly to use while I am sitting in front of my computer. So, am I going to switch to Jaiku? Well… I created a Jaiku account today but I am not sure yet… First I ‘ll try it, then I will decide… But in any case, posting through IM is preferred method of sending updates, so Jaiku, won’t win me over before they support IM unless Twitter looses me first…

If you do not know what Twitter is then look it up here.

Multiple calls to RegisterOnSubmitStatement and Client-Side Validation

rousso — Sat, 02 Dec 2006 08:54:00 +0000

Ok! Here is a new thing I discovered yet again the hard way…

In short: Do not call Page.ClientScript.RegisterOnSubmitStatement after the Page Load event.

(What?!)

Well yes! It’s not under all circumstances that you can notice the difference but it’s there and it’s major!

I do not really wan to describe this, so I ‘ll take you though it with an example:

Let’s say you have an aspx page. The page has two controls in it. For simplicity lets make those controls UserControls. The controls are pretty simple: just a TextBox and a RequiredFieldValidator in each of them.

So there you have it:

Control A (let’s call it OnSubmitControlA):

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="OnSubmitControlA.ascx.cs" Inherits="OnSubmitControlA" %>

and the code file:

public partial class OnSubmitControlA : System.Web.UI.UserControl
{
   protected override void OnPreRender(EventArgs e)
   {
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
      base.OnPreRender(e);
   }
}

Control B (let’s call it OnSubmitControlB):

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="OnSubmitControlB.ascx.cs" Inherits="OnSubmitControlB" %>

and the code file:

public partial class OnSubmitControlB : System.Web.UI.UserControl
{
   protected override void OnPreRender(EventArgs e)
   {
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
      base.OnPreRender(e);
   }
}

And finally the page itself:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="OnSubmitTest.aspx.cs" Inherits="OnSubmitTest" %>
<%@ Register Src="OnSubmitControlA.ascx" TagName="OnSubmitControlA" TagPrefix="uc1" %>
<%@ Register Src="OnSubmitControlB.ascx" TagName="OnSubmitControlB" TagPrefix="uc2" %>

   
      Test Page

(the codefile has nothing special in it…)

The page has of course a submit button so that we can submit and test it…

So! What we have here!?

A Page,
two controls that wan to access client-side code just before the page submits (for no particular reason)
and at least a Validator Control that will fail validation at some point. (If we did not have a validator then I would not have a case here!)

Now go render the page an see the result. If you leave either TextBox empty and click on the submit button, you will notice that only the alert from the first control pop’s up. The other registered script is never called….

Now go back and make a slight change. Move in both contols’ codefile the call to Page.ClientScript.RegisterOnSubmitStatement from OnPreRender to OnLoad, like this:

public partial class OnSubmitControlA : System.Web.UI.UserControl
{
   protected override void OnLoad(EventArgs e)
   {
      base.OnLoad(e);
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
   }
   protected override void OnPreRender(EventArgs e)
   {
      // Let's comment this out
      // Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomething", "alert('This alert is registered by OnSubmitControlA');");
      base.OnPreRender(e);
   }
}

do the same on the other control:

public partial class OnSubmitControlB : System.Web.UI.UserControl
{
   protected override void OnLoad(EventArgs e)
   {
      base.OnLoad(e);
      Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
   }
   protected override void OnPreRender(EventArgs e)
   {
      // Let's comment this out also
      // Page.ClientScript.RegisterOnSubmitStatement(this.GetType(), "DoingSomethingElse", "alert('This alert is registered by OnSubmitControlB');");
      base.OnPreRender(e);
   }
}

Done! Go back and render the page! Leave either TextBox empty and click submit… See??? Now both alerts pop up!!!

Why is that???

Well look at the source of the rendered page before and after the change to see what’ going on:

Here is the script rendered when the call to RegisterOnSubmitStatement is placed in the OnPreRender event:

And here is the script rendered when the call to RegisterOnSubmitStatement is placed in the OnLoad event:

Got it?

If RegisterOnSubmitStatement is called after OnLoad, then the first time it’s called the framework appends the statement that calls ValidatorOnSubmit() and returns false if it fails; (effectively blocking the rest of the script from executing). Subsequent calls of RegisterOnSubmitStatement (after OnLoad) are appended to the script generated by the first call (and get blocked by the effect I just described).

Instead, if all your calls to RegisterOnSubmitStatement come before the end of the OnLoad phase, then all registered scripts are appended to previously generated scripts before the eventual injection of the call to ValidatorOnSubmit().

Hoping for comments on this…

xsl:include, xsl:import & msxml:script blocked on WSS 3 XML WebParts

rousso — Wed, 29 Nov 2006 08:57:00 +0000

I discovered today (the hard way), that we can no longer use xsl:include and xsl:import elements in XSL Transformations for Windows SharePoint Services 3.0 XML WebParts.

Along with those msxml:script is also blocked.

I am going to investigate this further and see if there is an administrative way to bypass this security restriction. XSLT code reuse is a useful thing and I want to keep it as an option in some environments.

Anyhow…

I am including two relevant links I found on the web:

SharePoint DVWP: xslt limitations… in Serge van den Oever’s Blog
SharePoint Data View Web Part Extension Functions in the ddwrt Namespace in MSDN

I would appreciate comments from people who know more on the subject.

Moving to WSS 3

rousso — Sat, 25 Nov 2006 18:45:00 +0000

I am in the process of replacing my old personal site with a new version based on Windows SharePoint Services 3.0.

My previous site is based on Windows SharePoint Services 2.0, and is currently located at http://rousso.gr/.

Though I could just gradually upgrade the old site to the new version of WSS I opted not to do so because the last few months I have been considering of restructuring my sites completely. I am not currently getting into any more details on this, but the bottom line is that I came to have far too many personal sites which rendered my main site almost useless. On the other hand I need I WSS based site in order to enjoy the goodies of WSS like custom lists and document sharing with my family, friends and colleagues.

So what you can expect to see here is either a private site or a public site replacing the current versions of http://www.rousso.gr and http://blog.rousso.gr.

CS:Editor ViewState

rousso — Tue, 19 Sep 2006 07:58:00 +0000

Quick Tip:

CommunityServer 2.1 uses TinyMCE as a rich text editor. They use what appears to be a wrapper to TinyMCE: CommunityServer.Controls.Editor. As I am developing an application on top of CS 2.1 I am using the same rich text editor and encountered the following problem:

I was setting declaratively the Height Property of the Editor control, but it could not retain it’s value after postbacks.

Look at the ASPX part:

<%@ Register Assembly="CommunityServer.Controls" Namespace="CommunityServer.Controls" TagPrefix="CS" %>

So far so good but, after a postback the Editor control returned to its default height (messing-up my layout).

To make a long story short, it figured that something is wrong either with timing or with implementation. I mean that either the wrapper, or the wrapped control do not assign the value of Height before ViewState is saved, or they assign it to either a Property that is not saved in view state, or during an Event that fires before LoadViewState.

So what I did to work-around the issue was just disable ViewState in the Editor control.

The problem has gone away and that means that LoadViewState was overwriting my value.

I did not devote any time in looking further into this matter so I’m just posting this work-around, but if I do, I ‘ll let you know the details.

UseSubmitBehavior & GetPostBackEventReference

rousso — Mon, 29 May 2006 08:00:00 +0000

funny thing…

I needed a button (in an ASP.NET 2.0 page) to post-back and raise an event for another control. That means that I click a button but the post-back event is not handled by the button clicked but instead by another control on the same page.

The easy way was to add a System.Web.UI.WebControls.Hyperlink and set its NavigateUrl property to Page.ClientScript.GetPostBackClientHyperlink(myOtherControl, "Arguments")

But I wanted it to look like a Button so instead I added a System.Web.UI.HTMLControls.HTMLButton Control and did the same thing to its OnClientClick property.

All worked fine.

The funny thing happened when I decided that I like most to use a System.Web.UI.WebControls.Button instead.

ASP.NET Buttons are rendered as ="submit" /> controls. and by default their client-side onClick event is wired to the __doPostBack javascript method by ASP.NET.

To change that behavior in ASP.NET 2.0 we are supposed to use the UseSubmitBehavior Property which when set to false causes the Button to be rendered as "button" /> and allows you to set the client-side onClick event programmatically (or declaratively) by setting the OnClientClick server-side Property.

That’s what I did, only to discover that to whatever I was assigning to the OnClientClick Property, the original __doPostBack call was automatically appended by the framework.

I did not spend all the time in the world to figure this out and as I failed to find a reasonable way out of the problem, what I did, was to trick the client-side out of it by appending a JavaScript “return;” statement to the script I was assigning to OnClicntClick.

To make all these more obvious here is the hands on:

in the aspx/ascx file:

...

Notice that lines 5 and 6 above define the Hyperlink and HTMLButton that worked fine and line 7 defines the WebControls.Button that did not behave. Lines 1 to 3 define a DetailsView just because that is the control I wanted to handle the post-back event.

Now in the code file:

HyperLink1.NavigateUrl = Page.ClientScript.GetPostBackClientHyperlink(DetailsView1, "New$0", true);
Button1.Attributes.Add("onClick", Page.ClientScript.GetPostBackClientHyperlink(DetailsView1, "New$0", true));
Button2.UseSubmitBehavior = false;
Button2.OnClientClick = Page.ClientScript.GetPostBackEventReference(DetailsView1, "New$0");

These get rendered as follows at run-time (if you look at the source in the browser):

HyperLink

This works just fine if you click on the Hyperlink1 or Button1 controls, but not at all if you clicked at Button2. That is because Button2 makes the call to __doPostBack twice. Once because I asked it to do so (by assigning its OnClientClick Property as you see in line 4 of the code-file above) and once because the framework automatically inserted the default post-back event reference for the button (Button2) itself.

To overcome this behavior (as I could not find another way around it) I just changed the last line in the code-file (line 4 in the snippet) by appending a javascript return statement as follows:

Button2.OnClientClick = Page.ClientScript.GetPostBackEventReference(DetailsView1, "New$0") + "; return;";

This caused Button2 to render as follows:

Notice the return statement (in bold) rendered between the two calls to __doPostBack. Although this does not prevent the second __doPostBack call from beeing inserted by the framework, it does prevent it from executing….

If you know a proper way out of this little puzzle please let me know….

P.S:

As you obviously noticed I needed the button to create an Insert button that would enable a DetailsView to go to Insert Mode even if the view has no items to display. The button (when clicked) causes the DetailsView to receive an Insert Command.
Of course you fortunately do not need to do all this to make a details view to enter Insert Mode. It would be enough to just and any button with a server-side Click event handler changing the mode to Insert by just calling DetailsView1.ChangeMode(DetailsViewModes.Insert);

Hiding a Report Parameter in SQL Server 2000 Reporting Services

rousso — Fri, 05 May 2006 08:02:00 +0000

Situation:

You use SQL 2000 Reporting Services, to create a report (probably same applies for SQL 2005, but I have not tried it yet).

You report expects various parameters but the user does not need to specify all of them through the user interface. For example the value of a parameter (say ParamB) can be calculated based on the value of another parameter (say ParamA) that the user selects.

So, you want to hide ParamB from the user.

Solution:

In the Report Parameters Collection Editor select the parameter that you want to hide and clear its “Prompt” field. Then add a Default Value to it (either by using an expression or by using a query).

Quick Tip:

Notice that when you use a query to get the default value of the hidden parameter ParamB you can always pass to it the Value that the user selected for ParamA (or another parameter).