Fri, 03/09/2010 - 13:29
I may have overlooked something, but I didn't see the overall width and height of the VMS (without mounting / framework) in the VmsTablePublication (VmsRecord). This would be needed to show the VMS accurately in a graphical representation.
I'm also not sure whether a static "background picture" which contains static, "painted" parts of a VMS, can be represented accurately by the Pictogram element.
I'm talking about VMS looking like this: http://images.google.de/images?&q=dwista. I do not see a pictogramURL in the VmsTablePublication, so it doesn't seem possible to provide a static picture. Maybe this could be added because it doesn't seem to make sense to send a background picture repeatedly with every VmsMessage.
It appears that you have some valid requirements which are not currently addressed by the model.
I think to address your requirements the following should be added to the VmsRecord in the VmsTablePublication
- overall width and height attributes
- an attribute to point to a URL for the static "painted" part of the VMS.
Looking at the examples of VMS with "painted" backgrounds that you have referenced it seems that where the sign is covering several lanes the information for each lane could be modelled as a separate VMS (albeit controlled by a single VMS Unit), each having a different lane location and having its own static "painted" part and individual displayed "message" (comprising text and pictograms).
I think the above solution would meet your requirements.
I agree with adding the attributes width, height and an image URL for the static background of the VMS to VmsRecord.
Modeling one big physical VMS as several logical VMS does not seem to be the best solution to me. In the examples it can be seen that VMS cannot always easily be partitioned along the lanes, often there are 2 text areas for 3 lanes. It would also be difficult to distinguish between VMS that are physically or just "logically" separated and to picture them correctly in an application.
I think this second issue should be discussed further in the topic http://www.datex2.eu/content/vms-content-multiple-layouts-text-areas.
I try to add my comments on the topic:
The rational behind the model was to use different VMS for different usage of phisically distinct text areas and/or pictograms.
VMS can be related not only to lanes but also to different destination: Logic location of VMS is available to manage specific location (area/point/linear) destination in DATEX location package.
The need to specify the underlying painted information around the VMS was not considered initially, based on the fact that this is mostly relevant to this logical destination as it happens in most cases that were known by the modeling team at that time. It could be considered to have the exact shape and paints represented by the static information described by Tim. but this seems not relevant to understand the usage of the VMS which mainly relies on above mentioned logic location.
Finally as the initial focus was to exchange the usage of VMS no need was considered to specify exact width and height that can be modeled as optional attributes in the static part if effectively needed.