Difference between revisions of "Talk:BRGINF"
| (5 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) | + | [[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 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.