Talk:VSLUNT

jens 09:22, 13 October 2010 (UTC) all looks fine so far. I'm a bit in doubt about net and gross tonnage. GT and NT are defined with no units. One declares "The vessel has a NT of 5000". No extra unit is needed, therefore I guess they are wrong here. Having them defined at VSLCAR is sufficient.
DavidAcland 11:22, 20 October 2010 (UTC)
I am can see the benefits of your quarantined additions. Theoretically as numbers, a unit is not required, but this only works if you use the UKHO approach, which is a fudge and only works grammatically. However if we do not use a unit for Gross and Net tonnages, we lose rigour. We would also have to change the multiplicity of VSLUNT to 0..1. I guess the encoding software and ECDISs would then have to enforce or only offer appropriate unit options for each type of characteristic. In the case of Gross and Net tonnages it would also have to prevent the VSLUNT being completed.
However this approach will not work in practice because the Suez and Panama Canals and all their customers talk about "Gross tons" and "Net tons".
On the other hand if we take your proposals, we keep VSLUNT as mandatory, maintaining rigour, and I think that that is important. We also do what the industry does. I have added a sentence to VSLCAR in both cases to say that they are not strictly speaking weight units. So I am prepared to lift the quarantine and see how it looks. I conclude that Suez and Panama net tonnages are so fundamental to ship classification that they will need their own fields and therefore their own units.

jens 04:57, 22 October 2010 (UTC)
I totally understand your objections. I only feel a little pain in my mind when trying to give units where definitely no units exist. The German interpretation is similar to the UK version; no unit! In my opinion we can add a further value to VSLUNT saying "none". That would make it clear to the software and encoding people and goes beyond the currently used value "unknown" for uncertain information in ENC.
Additionally "none" makes the multiplicity bijective. The future display may provide:

   
"Length over all = 100.00 metre 
   
 Net Tonnage = 12000
   
 Height= 30,5 foot"

"none" should be interpreted as "display nothing".
We should hear if Raphael provides advice from the software point of view.

DavidAcland 14:02, 5 November 2010 (UTC)
Agree to try "None".

raphael 16:50, 5 November 2010 (UTC): There is indeed a unit ("gross tons", which is a unit of volume), but it is not explicitly written in publications because natural languages often diverge from strict logic.

"None" works from the software point of view, explicitly saying "none" is as good as specifying a unit. We can add "none" but should retain gross tons and net tons as allowed values for situations where the style is to write out the unit but not the type of quantity (natural language again...).
I don't know enough about other languages to say whether a linguistic formulation that works in English and German works in them too. And consider situations where the display writes short sentences instead of a tabulation like the one in Jens' 22 October post.
Summary: Add "none" but keep gross tons and net tons.

jens 10:52, 8 November 2010 (UTC) ok, that convinces me. We keep NT, GT and SuezGT as an option if languages or sentence constructions need that.

DavidAcland 15:33, 8 November 2010 (UTC) OK. I am happy to keep net tons (NT) and gross tons (GT) plus the Suez and Panama derivatives. In that case, we do not need "None". I will rework the language, and your examples where I find them Jens.

jens 17:57, 8 November 2010 (UTC) Save none! Keep NT, GT etc.. Why that? See Raphael's post summary 5 Nov.
See, actually we have a duplication at NT, GT and their derivatives Suez/Panama now. Using the complexity completely I can write Net Tonnage=5000 NT, or Net Tonnage=5000. Both works according to the decision developed above. Especially Raphael's linguistic argument convinced me to leave my strict German view.
So again, Save "none"!

DavidAcland 14:34, 31 January 2011 (UTC) Back on the case after a 3 month break. br> OK. "None" stays.

raphael 18:43, 12 August 2011 (UTC): Do we also need twenty-foot equivalent units (TEU) as a measure of cargo capacity for container ships?

DavidAcland 09:42, 15 August 2011 (UTC) In principle I can see where your are coming form Raphael because TEUs are a messure of cargo carrying capacity which is a bit like net tonnage or displacement tonnage. However I agree with Jens on TEUs. The number of TEUs are not a precise measurement. In fact, some companies are notorious for under reporting this figure in their ships. The equivalent for Ro-Ros is lane-metres.

These two parameters are normally quoted for new builds or for advertising new vessels in a service. So they tend to be associated with commercial operations and get distorted up or down.

If we find regulation, which uses these parameters or the need becomes clearer (for instance charges become based on either of these figures) we can review the decision and add either or both to the model. The question would then be whether they should be in this attribute, in VSLCAR, or both.

raphael 01:31, 29 June 2013 (UTC): There is a discrepancy between the current name of this attribute (vessel units) and the VSLMSM page, where it is called vesselsCharacteristicsUnit.

raphael (talk) 05:23, 6 February 2017 (CET): Definition: the unit used for vessel characteristics attribute (Registry link)

raphael (talk) 05:10, 7 February 2017 (CET): Allowing different units for the same characteristic means developers must be extra careful to convert units when processing. On the other hand, standardizing on a single unit for a characteristic means encoders must be extra careful when creating the original data. Dilemma.

raphael (talk) 19:46, 8 February 2017 (CET): If the GI registry defines a unified set of units of measure and a generic unitOfMeasure attribute we should consider replacing VSLUNT with that.

jens (talk) 10:07, 14 February 2017 (CET) The question is, who will initiate that? Should we add this or is it Jeff's job? Following Jeff's recent proposals, would it be a codelist?

raphael (talk) 06:07, 17 February 2017 (CET): I think Jeff should do it. There are already different lists of units in the GI rgistry. NIPWG could just make sure it gets on his to-do list. Codelist (open enumeration) seems the best, because some product specification might want to use a unit which is not on the current list.

raphael (talk) 09:10, 27 July 2017 (CEST): Code 11 is "cubic metres" (definition: "Cubic metres"), it was suggested in the previous round of reviews and is in the NIPWG4 draft.
Code 12 should be "Suez Canal Gross Tonnes".
Codes 8 and 9 should be corrected to use "tonnes" instead of "tonnage".