Difference between revisions of "Talk:BRGINF"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
However it will look, it should be a string. Although it is very tempting to say it can be numeric like 256 (degrees), I checked several image title saying "in xx bearing" others say "from xx". Both is opposite. It seems to be also impossible to specify what kind of bearing it will be; in SW or from SW or something else. So, string is fine, I guess.
 
However it will look, it should be a string. Although it is very tempting to say it can be numeric like 256 (degrees), I checked several image title saying "in xx bearing" others say "from xx". Both is opposite. It seems to be also impossible to specify what kind of bearing it will be; in SW or from SW or something else. So, string is fine, I guess.
  
[[User:Jens|jens]] 15:39, 19 February 2012 (UTC)Folllowing dicussion came up at SNPWG14. Bearing information stored ar string can not sufficiently accessed by software. Better would be to provide more options; e.g. degrees, cardinal directions, sector and strings. The cardinal directions should be coded in 16 values.  
+
[[User:Jens|jens]] 15:39, 19 February 2012 (UTC) Following dicussion came up at SNPWG14. Bearing information stored as string cannot be sufficiently accessed by software. Better would be to provide more options: e.g. degrees, cardinal directions, sector and strings. The cardinal directions should be coded in 16 values.  
 
<br>Is it feasable to replace the current string by a complex attribute which allows access to several options if applicable?
 
<br>Is it feasable to replace the current string by a complex attribute which allows access to several options if applicable?
 
<br>Meantime I have developed an attribute for the cardinal directions [[CARDIR]].
 
<br>Meantime I have developed an attribute for the cardinal directions [[CARDIR]].
 
<br>It was further agreed that the direction should be given from the observer's point.
 
<br>It was further agreed that the direction should be given from the observer's point.
  
[[User:Jens|jens]] 18:45, 20 February 2012 (UTC) started to develop a coplex attribute; SECTR1 and SECTR2 are S57 attributes. It is to check whether they can replace the direction attribute proposal at the table
+
[[User:Jens|jens]] 18:45, 20 February 2012 (UTC) started to develop a complex attribute; SECTR1 and SECTR2 are S57 attributes. It is to check whether they can replace the direction attribute proposal at the table
 +
 
 +
[[User:Rmm|raphael]] 01:50, 21 February 2012 (UTC): The S57 attribute ORIENT is an additional possibility.
 +
 
 +
[[User:Jens|jens]] 09:25, 22 February 2012 (UTC) Thanks Rapahel, ORIENT is incorporated.
 +
 
 +
[[User:Rmm|raphael]] 04:49, 5 August 2014 (UTC): The current S-101 DCEG baseline uses complex attributes for sector limits and orientation, suggest changing the sector limit and orientation sub-attributes accordingly for harmonising with S-101. (The MPA feature types diagram I just uploaded shows the S-101 model.)
 +
 
 +
[[User:Rmm|raphael]] ([[User talk:Rmm|talk]]) 06:20, 30 May 2017 (CEST): Jens and I considered replacing 'distance' with 'approximate distance' (a string type) (there is a summary of the discussion on [[Talk:DISTNC]] page). Among the points made there are:
 +
* approximate distance should suffice for 'bearing information' as an attribute for describing photographs and other graphics.
 +
* Location cannot be automatically generated with the proposed string:approximateDistance, but:
 +
** the use case for requiring automatic generation of locations is still to be made;
 +
** distances for photographs and other graphics are likely to be approximate anyway;
 +
** if there is a need for precise distances, the existing Hydro domain attribute 'measured distance' can be added as another sub-attribute.

Latest revision as of 04:20, 30 May 2017

jens 11:32, 28 July 2011 (UTC)
However it will look, it should be a string. Although it is very tempting to say it can be numeric like 256 (degrees), I checked several image title saying "in xx bearing" others say "from xx". Both is opposite. It seems to be also impossible to specify what kind of bearing it will be; in SW or from SW or something else. So, string is fine, I guess.

jens 15:39, 19 February 2012 (UTC) Following dicussion came up at SNPWG14. Bearing information stored as string cannot be sufficiently accessed by software. Better would be to provide more options: e.g. degrees, cardinal directions, sector and strings. The cardinal directions should be coded in 16 values.
Is it feasable to replace the current string by a complex attribute which allows access to several options if applicable?
Meantime I have developed an attribute for the cardinal directions CARDIR.
It was further agreed that the direction should be given from the observer's point.

jens 18:45, 20 February 2012 (UTC) started to develop a complex attribute; SECTR1 and SECTR2 are S57 attributes. It is to check whether they can replace the direction attribute proposal at the table

raphael 01:50, 21 February 2012 (UTC): The S57 attribute ORIENT is an additional possibility.

jens 09:25, 22 February 2012 (UTC) Thanks Rapahel, ORIENT is incorporated.

raphael 04:49, 5 August 2014 (UTC): The current S-101 DCEG baseline uses complex attributes for sector limits and orientation, suggest changing the sector limit and orientation sub-attributes accordingly for harmonising with S-101. (The MPA feature types diagram I just uploaded shows the S-101 model.)

raphael (talk) 06:20, 30 May 2017 (CEST): Jens and I considered replacing 'distance' with 'approximate distance' (a string type) (there is a summary of the discussion on Talk:DISTNC page). Among the points made there are:

  • approximate distance should suffice for 'bearing information' as an attribute for describing photographs and other graphics.
  • Location cannot be automatically generated with the proposed string:approximateDistance, but:
    • the use case for requiring automatic generation of locations is still to be made;
    • distances for photographs and other graphics are likely to be approximate anyway;
    • if there is a need for precise distances, the existing Hydro domain attribute 'measured distance' can be added as another sub-attribute.