Talk:CNTRNM - Revision history

Rmm at 21:51, 1 June 2017

2017-06-01T21:51:44Z

Jens: Jens moved page Talk:CONTRY to Talk:CNTRNM: changed "country" to "countryName"

2017-05-30T19:02:11Z

Jens moved page Talk:CONTRY to Talk:CNTRNM: changed "country" to "countryName"

Rmm at 17:29, 23 January 2017

2017-01-23T17:29:12Z

Jens at 05:52, 23 January 2017

2017-01-23T05:52:40Z

Rmm at 15:35, 19 January 2017

2017-01-19T15:35:21Z

Jens at 09:25, 13 November 2012

2012-11-13T09:25:06Z

New page

Agreed by SNPWG8

Submitted to Hydro register manager Date

Submitted to Nav register manager Date

[[User:Jens|jens]] 09:25, 13 November 2012 (UTC) this has to be replaced by the country codes used for S57.

Jens: New page: Agreed by SNPWG8 Submitted to Hydro register manager Date Submitted to Nav register manager Date

2008-07-20T16:29:12Z

New page: Agreed by SNPWG8 Submitted to Hydro register manager Date Submitted to Nav register manager Date

New page

Agreed by SNPWG8

Submitted to Hydro register manager Date

Submitted to Nav register manager Date

← Older revision		Revision as of 21:51, 1 June 2017
Line 18:		Line 18:

	[[User:Rmm\|raphael]] ([[User talk:Rmm\|talk]]) 18:29, 23 January 2017 (CET): Edited to clarify that 'this attribute' in my previous comment means 'country'. No change to my recommendation to leave it as a string type pending a global solution.		[[User:Rmm\|raphael]] ([[User talk:Rmm\|talk]]) 18:29, 23 January 2017 (CET): Edited to clarify that 'this attribute' in my previous comment means 'country'. No change to my recommendation to leave it as a string type pending a global solution.
		+
		+	[[User:Rmm\|raphael]] ([[User talk:Rmm\|talk]]) 23:51, 1 June 2017 (CEST): After e-mail discussions between Jens, Julia, and me, 'country' was renamed as 'country name' and is distinguished from 'country code' / 'nationality' (the latter would be used for ISO 3166 country codes). The question may be reopened if and when the new ISO address model is integrated into S-100 but that is a matter for later editions of product specifications.

@@ Line 11: / Line 11: @@
 To be clarified. NPUB seems to be using this in only one place, as a sub-attribute of [[sourceIndication]]. A codelist would reduce data volume slightly at the cost of increased complexity. If we change it to codelist I’d suggest an open or closed dictionary.
-There is the existing attribute ''nationality'' whose content is the ISO 3166 country code. I think the original reason for defining this attribute was to allow encoding the 'full names' of countries. With a dictionary codelist type the full name could be in the dictionary and the short 2-letter code or a numeric code encoded in the data. Whether there would actually be an overall saving in data volume is not easy to say, because the saving in data value storage would be counterbalanced by the storage requirements for the dictionary, and the first would be at the level of individual datasets and exchange sets and the second at either exchange set or system level. Implementation complexity is another consideration. Further, there's about 200 countries in the world even if many are not coastal states, that's a rather large enumeration or codelist in the feature catalogue.
+There is the existing attribute ''nationality'' whose content is the ISO 3166 country code. I think the original reason for defining this attribute (''country'') was to allow encoding the 'full names' of countries. With a dictionary codelist type the full name could be in the dictionary and the short 2-letter code or a numeric code encoded in the data. Whether there would actually be an overall saving in data volume is not easy to say, because the saving in data value storage would be counterbalanced by the storage requirements for the dictionary, and the first would be at the level of individual datasets and exchange sets and the second at either exchange set or system level. Implementation complexity is another consideration. Further, there's about 200 countries in the world even if many are not coastal states, that's a rather large enumeration or codelist in the feature catalogue.
 All in all, I think the matter is complex enough to leave it as a string type for now, perhaps pending a global solution applicable to multiple S-100 based data products.
 [[User:Jens|jens]] ([[User talk:Jens|talk]]) 06:52, 23 January 2017 (CET) I agree with Raphael. Let it stay as a string type and reconsider if S-100 might find a better solution which would satisfy multiple s-100 based dat products.

← Older revision		Revision as of 05:52, 23 January 2017
Line 14:		Line 14:

	All in all, I think the matter is complex enough to leave it as a string type for now, perhaps pending a global solution applicable to multiple S-100 based data products.		All in all, I think the matter is complex enough to leave it as a string type for now, perhaps pending a global solution applicable to multiple S-100 based data products.
		+
		+	[[User:Jens\|jens]] ([[User talk:Jens\|talk]]) 06:52, 23 January 2017 (CET) I agree with Raphael. Let it stay as a string type and reconsider if S-100 might find a better solution which would satisfy multiple s-100 based dat products.

← Older revision		Revision as of 15:35, 19 January 2017
Line 6:		Line 6:

	[[User:Jens\|jens]] 09:25, 13 November 2012 (UTC) this has to be replaced by the country codes used for S57.		[[User:Jens\|jens]] 09:25, 13 November 2012 (UTC) this has to be replaced by the country codes used for S57.
		+
		+	[[User:Rmm\|raphael]] ([[User talk:Rmm\|talk]]) 16:35, 19 January 2017 (CET): Feedback received: Wouldn't this be better as a code list?
		+
		+	To be clarified. NPUB seems to be using this in only one place, as a sub-attribute of [[sourceIndication]]. A codelist would reduce data volume slightly at the cost of increased complexity. If we change it to codelist I’d suggest an open or closed dictionary.
		+
		+	There is the existing attribute ''nationality'' whose content is the ISO 3166 country code. I think the original reason for defining this attribute was to allow encoding the 'full names' of countries. With a dictionary codelist type the full name could be in the dictionary and the short 2-letter code or a numeric code encoded in the data. Whether there would actually be an overall saving in data volume is not easy to say, because the saving in data value storage would be counterbalanced by the storage requirements for the dictionary, and the first would be at the level of individual datasets and exchange sets and the second at either exchange set or system level. Implementation complexity is another consideration. Further, there's about 200 countries in the world even if many are not coastal states, that's a rather large enumeration or codelist in the feature catalogue.
		+
		+	All in all, I think the matter is complex enough to leave it as a string type for now, perhaps pending a global solution applicable to multiple S-100 based data products.

← Older revision	Revision as of 19:02, 30 May 2017
(No difference)