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 life difficult. We can either:

i) use the existing ?UNITS and add those for tonnage (as we already proposed years ago, but this was not posted to TSMAD either by Peter or by Hannes - seems to me it was not opportune in that time (we were a few steps too far ahead)), or

ii) use our own units attribute.

In i) we force the encoder to convert given units to those specified by ?UNITS; in ii) we can presumably 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 we decide to use ii)
My vote is ii).

DavidAcland 13:44, 4 October 2010 (UTC)

OK I will try and draft Jens' ii). I think it makes sense to have a unit attribute when we have such strange units as net tons, which are actually an expression of volume.

"Air draught" has been removed from NP100. The equivalent term is now "height", which I have now inserted.

DavidAcland 12:24, 5 October 2010 (UTC)
Jens, I have noticed that Wikipedia gives two definitons for Deadweight tonnage. I have added the second on our page. This set me to look at NP100. Here I found the following:

"Traditional tonnage measurements

Displacement tonnage is the weight of water displaced by a vessel and is equal to her weight and all that is in her. Hence, displacement in tons equals the volume of water displaced (in cubic feet) divided by 35 or 36, according to whether the water is salt or fresh respectively. Displacement may also be quoted in tonnes.

Deadweight tonnage is the weight, in tons of 2240 lb or tonnes of 1000 kilograms, of cargo, stores, fuel, passengers and crew carried by a vessel when loaded to her maximum summer load line.

Gross tonnage is measured according to the law of the national authority with which a vessel is registered. This measurement is, broadly, the capacity in cubic feet of the spaces within the hull and of the enclosed spaces above the deck available for cargo, stores, passengers and crew, with certain exceptions, divided by 100. Thus, 100 cubic feet of capacity is equivalent to 1 gross ton.

Net tonnage is derived from gross tonnage by deducting spaces used for the accommodation of crew, navigation, machinery and fuel.

Suez and Panama Canal tonnages. Both Canal authorities have their own rules for the measurement of gross and net tonnage and ships using the canals are charged on these tonnages.

IMO tonnage measurements

Current tonnage regulations give effect to the International Convention on the Tonnage Measurement of Ships, 1969, convened by IMO.

Gross tonnage under these regulations is derived from the moulded volume of the enclosed spaces of the entire vessel: it is used for comparing the size of one vessel with another. Most safety regulations are based on it.

Net tonnage is derived from a formula based on the volume of the cargo spaces, the number of passengers carried, the moulded depth of the vessel, and her summer draught: it is used as an indication of earning capacity, and for assessing dues and charges.

Units are not employed: values obtained from the formulae are expressed directly as the “gross tonnage” or “net tonnage”."

I have looked at the International Convention on the Tonnage Measurement of Ships. This is too detailed and does not offer quotable definitions for us.

NP100 is slightly different to Wikipedia in a number of areas. I also looked back at the Previous Edition of NP100 and found that there were no substantive changes in either edition. This means that the language has been stable for 10 years and it mentions the Convention of 1969. I think that in this area NP100 may be a better authority than Wikipedia. I like the rigour and precision of these extracts - but then you would probably expect me to appreciate them. I also find the comment about Units significant.
If we take the NP100 line, we should not be using units for gross and net tonnage. This would make VSLUNT conditionally mandatory as well: i.e. VSLUNT is mandatory for breadth, height, lengths, deadweight and displacement tonnages but should not be used for gross and net tonnages.
Are we bijective enought yet? It would be good to capture this in the model but I cannot see how.
Any ideas?
If we cannot, it will have to go into the Encoding Guide.

raphael 04:30, 8 October 2010 (UTC): About "height". OEMs tend to use these labels in end-user software, and plain "height" might be ambiguous to some end-users, especially in connection with yachts. If we do away with "air draught", "height from waterline" may be better than plain "height"?

raphael 06:42, 8 October 2010 (UTC): About units for gross and net tonnage:

• VSLUNT is redundant because there is only one possible unit for each, so from a purely modeling perspective I have no problem omitting it.
• I looked at the US Coast Pilot and (translated) BSH sailing directions, and they mention the unit but not the quantity type. They use phraseology like "vessels greater than 1600 gross tons", "each vessel greater than 300 gross tons", etc. The common ground with NP100 is that locutions like "gross tonnage greater than 1000 gross tonnes" are awkward.
• I am a bit concerned about how omitting VSLUNT complicates software development, including data validators and editors. It would be a "special-case rule" which are the bane of software developers.

Summary: I agree with omitting VSLUNT for gross tonnage and net tonnage. If it turns out to cause significant software development or portrayal problems, I might be back later arguing for a change.

jens 09:44, 13 October 2010 (UTC) I spotted the NT GT problem at VSLUNT before having read the text above. I agree to remove GT and NT form the VSLUNT values and will put them under quarantine to ban them or reanimate if appropriate.

DavidAcland 14:26, 5 November 2010 (UTC) Back on the case. I like Jens' VSLUNT = None suggestion. We can then use this for all net and gross tonnage characteristics. As the Panama and Suez canal figures exist for many vesssels, possibly most, and they are a characteristic of the vessel, I have transfered them to here. This will allow HOs and OEMs to include the characteristic with a VSLUNT of "None" and we can still make the unit mandatory so no "special-case" rule is needed.
On Raphael's concern of "height" in yachts, this is covered nicely by "masthead height" in the definition. Unless I am missing something, this works just fine for me.
When the dust settles we should reorder this attribute to something like: lengths, breadth, height, weights, tonnages.

DavidAcland 16:07, 8 November 2010 (UTC) Going full circle. See discussion at VSLUNT to reinstate gross and net tons as units, even thought they are a sort of volumetric unit.
Reordered i.a.w. above.

DavidAcland 15:25, 31 January 2011 (UTC) Our current definiton for draught is too restrictive. Vessels have draughts even if they are not full loaded. I therefore propose the definition from NP100 as an alternative.

--jens 05:46, 1 February 2011 (UTC) ok David, I agree. I will delete the depreciated definition.

raphael (talk) 05:20, 6 February 2017 (CET): Proposed definition: Characteristics of vessels.
Remarks: This is an enumeration of different properties of vessels which are often used in specifying whether they are subject to rules or restrictions.
The properties covered by this attribute are those of the vessel itself, such as dimensional and tonnage properties. The type of vessel and the cargo carried by a vessel are characterized by different attributes (see categoryOfVessel, categoryOfCargo, categoryOfDangerousOrHazardousCargo).