Talk:VSLCAR

jens 13:02, 24 July 2010 (UTC) I'm really sure, that this list can be extended due to several reasons.

It is to be considered if we should add the units here. Only a given value makes no sense. (think about tons and long tons, metre vs foot etc.)

DavidAcland 15:50, 13 August 2010 (UTC)

I am tempted. Without units somewhere, we cannot use a flexible model like this when VSLCAR is an integer but for very different characteristics.

However we will get into trouble with draught and feet and metres; probably some others.

Could we have a unit attribute with values like:

metres, feet, tonnes, gross tonnage, net tonnage?

raphael 20:16, 13 August 2010 (UTC): I assume the dataset will have parameters that specify the units it uses for depths, etc., like HUNITS, DUNITS, and PUNITS in S-57. Maybe S-100 has something to say about this? In general I am somewhat reluctant to allow a dataset to specify units at a fine-grained level, I think it increases the chances of an encoding or programming error. But it is indeed tempting, especially in connection with long tons and gross tons and converting feet to metres. Let's think about this for a few days and see if there are compelling arguments for either alternative.

DavidAcland 10:08, 15 August 2010 (UTC)

Thanks for this. I think I understand how HUNITS and DUNITS work in a chart product. I come unstuck when thinking about tanker draughts. That trade seems to work in feet, if not universally, far more so than most other shipping.

So if we take the line suggested by Raphael for HUNITS and DUNITS and then an HO specified metres for a datset, I imagine that production software could be configured to accept either feet or meters for say Regulation and then make the convertion to the units specified for the current data set. A similar optional input followed by conversion would have to be available in the ECDIS for input of ship's draught, breadth, LOA etc. Perhaps it already is?

jens 06:05, 16 August 2010 (UTC)
Indeed, we have to distinguish between the back end and the front end.
In the front end, the ECDIS system settings are either limited to specific units or do the conversion automatically. That is not the problem.
The back end makes the live difficult. We can i)either use the existing ?UNITS and add those for tonnage (as we already proposed years ago, but is was not posted to TSMAD neither by Peter nor by Hannes - seems to my it was not opportune in that time (we were few steps too far ahead)) or ii) use our own units attribute. In i) we force the encoder to converse given units to those specified by ?UNITS, in ii) we can presumable input 1:1 but may encounter problems as Raphael pointed out (post 13 August).
Option i) requires a revision of the current definitions of ?UNITS and to allow their use in ENC again (not only in Meta data as it is now), ii) gives us more flexibility.
We have to consider that VSLMSM might be multiplied if deciding use ii)
My vote is ii).