Difference between revisions of "Talk:Sandbox"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
Line 87: Line 87:
  
  
== draft for Wreck feature class ==
 
  
 
 
== draft for Obstruction feature class ==
 
 
GEO OBJECT CLASSES
 
 
Feature: Obstruction
 
 
Acronym: OBSTRN
 
 
Camel case: Obstruction
 
 
Spatial: point, curve, surface
 
 
 
Simple Attributes:  '''CATOBS'''; '''CONDTN'''; '''EXPSOU'''; '''HEIGHT'''; '''maximumPermittedDraught'''; '''QUASOU'''; '''[[REPDAT]]'''; '''[[STATUS]]'''; '''TECSOU'''; '''VALSOU'''; '''VERLEN'''; '''verticalUncertainty'''; '''WATLEV''';
 
SCAMAX; SCAMIN;
 
 
Complex Attributes:  '''[[fixedDateRange]]'''; '''[[name]]'''; '''[[PeriodicDateRange]]''';  '''[[SourceIndication]]''';  '''[[TXTCON]]''';
 
 
Associated information object classes: '''[[NATINF]]'''; '''[[RCMDTS]]'''; '''[[REGLTS]]'''; '''[[RESDES]]''';
 
 
 
 
Definition:
 
 
In marine navigation, anything that hinders or prevents movement, especially anything that endangers or prevents passage of a vessel. The term is usually used to refer to an isolted danger to navigation, such as a sunken rock or pinnacle.
 
 
References:
 
 
INT 1: ???????????
 
 
M-3: 
 
 
M-4: ???????????
 
 
IHO Dictionary - S32
 
 
Remarks:
 
 
See the S-101 DCEG clauses 13.6.1 for general encoding rules.
 
<br>
 
Specific rules for S-122 (MPA):
 
* S-122 data sets can encode only Obstruction features corresponding to fish havens or artificial reefs (category of obstruction = 5 or 14).
 
* Features that are considered to be subsurface Fish Aggregating Devices (FAD) must be encoded as Obstruction, with category of obstruction = 5 (fish haven), unless the FAD is a vessel which has been deliberately sunk to form a fish haven, which should be encoded as a Wreck feature. (ref. 13.6.1 S-101 DCEG - April 2014 baseline).
 
 
Distinction: 
 
 
Depth Area; Fishing Facility; Foul Ground; Marine Farm/Fulture; Underwater Rock; Water Turbulence; [[WRECKS|Wreck]]
 
 
Justification:<br>
 
S-101 feature used in S-122 to encode fish havens and artificial reefs.
 
<br>
 
 
Comment:
 
 
The following S-101 attributes are not bound to '''Obstruction''' features in the S-122 application schema and should not be encoded in S-122 datasets. Applications should ignore their presence in '''Obstruction''' features which are part of S-122 datasets.
 
* PRODCT product
 
* NATSUR nature of surface
 
  
 
== attributes defined in S-101 ==
 
== attributes defined in S-101 ==

Revision as of 20:24, 17 October 2015

jens 15:18, 12 April 2014 (UTC)
SNPWG17 decided to make telecommunications complex. That based on the assumption that it would be necessary to provide more specific satellite service information like prefix of different sat services, areas on which specific access codes have to be used to connect tx and rx. The entries here are been made to discuss how it should look like and the possible effects on the current MPA and radio service application scheme.


It has to be considered if SRVHRS can somehow combined with this complex attribute. That would make after office hours number superfluous.

raphael 21:33, 5 May 2014 (UTC): how about generalizing communicationIdentityOutSideWorkingHours to an enumeration accessTime, operatingTimes, or access (?) with the following allowed values:
1: during usual working hours
2: out of usual working hours

This can be used in situations other than communications, and also used if we want to specify something is available or can be used both within and outside working hours.

Shorter camel case names would be better. Also, no one will be able to remember whether it is communications... or communication...

raphael 00:49, 8 May 2014 (UTC): The January 2014 S-101 DCEG defines both "web address" and "telephone number" attributes. More meat for the harmonization discussion.

raphael 01:33, 10 May 2014 (UTC): Let's re-organize CONDET address attributes into a new "address" complex attribute, that will allow multiple delivery addresses too.

ISO 19115:2014 defines class CI_Contact with many similarities to CONDET, and defines a CI_Address type with attributes similar to the CONDET physical/delivery address attributes. I think that is mostly a good idea.


jens 18:11, 12 May 2014 (UTC) I agree with both proposals, the accessTime idea and the idea to make CONDET a address complex attribute. For the latter, should we rename that too or should be proceed with CONDET?

raphael 03:40, 13 May 2014 (UTC): Proposed revised model of CONDET, figure below. I will replace attributes EMAILS and ADRNET with enumerants of telcomService if you insist but I think it would be overloading the concept, makes it difficult to define complex attribute telecommunications, and raises a question about modeling radio communications information with CALNAM and CALSGN attributes. Also ADRNET is a sub-attribute of complex attribute TXTCON.

Proposed CONDET model


Definitions: File:CONDET WIP.pdf
Suggestions or opinions about the methods used for making more compact diagrams are also invited. If I draw them using the "ordinary" conventions, either some boxes stretch three quarters of the page width, or we get tangles of "wiring diagrams".

jens 09:21, 14 May 2014 (UTC)At first, I like the new diagram very much. It is better to read and better to understand. In fact, I believe even people with no experience would be able to read this.

I think that ADRNET might have only one instance. That confirms your idea of having it still as an extra attribute. Regarding EMAILS I have a slightly different view. It could be that an organisation has several emails and we need to model more than one instance. Email is a data transfer. One can see it academic and say that digital phone is also data transfer but I think nobody would easily adopt that. Thus, I still believe that incorporating email might be a good idea.

draft association class detail page

ASSOCIATION CLASS

Association name: Permission Type

Acronym: PERMIS

Camel Case: PermissionType

Simple Attributes: CATREL [1..1]

Complex Attributes: none

Roles:

Source Target Navigability Remarks
Role name Feature or Info type Multiplicity Role name Feature or Info type Multiplicity
vslLocation InformationArea 0..* permission Applicability 0..* n/a
vslLocation (any feature) 0..* permission Applicability 0..* source → target


Definition:

Association class for associations describing whether the subsets of vessels determined by the ship characteristics specified in APPLIC may (or must, etc.) transit, enter, or use a feature.


References:

Remarks: No remarks

Justification:

Comments:


Jens Raphael Other
Y/N Y/N Y/N





attributes defined in S-101

Simple attributes defined in S-101 and used in Wreck and Obstruction feature classes:

  • CATOBS category of obstruction
  • CATWRK category of wreck
  • CONDTN condition
  • CONRAD radar conspicuous
  • CONVIS visually conspicuous
  • EXPSOU exposition of sounding
  • HEIGHT height
  • maximumPermittedDraught maximum permitted draught
  • QUASOU quality of sounding measurement
  • STATUS status
  • TECSOU technique of vertical measurement
  • WATLEV water level effect