Talk:DISTNC
raphael (talk) 05:47, 30 May 2017 (CEST): Following feedback from Julia and Jeff about while entering it into the GI registry about whether the existing attribute "measured distance" should replace this attribute, Jens and I discussed it and propose instead changing this attribute to "approximate distance".
Name: approximate distance
Acronym: APXDST (?)
Camel case: approximateDistance
Definition: An estimated or approximate distance between two locations.
Type: String
Examples: 2 NM; 500 metres; 4 cables.
Points discussed:
- 'measured distance' is defined in the GI registry as 'An accurately defined distance along a course at sea.' Many photographs (for example) may not be taken from an accurately measured distance, so using 'measured distance' in BRGINF would confuse encoders as to whether they can encode a value for this attribute if the distance is only estimated or approximate.
- 'Distance', as originally defined on this wiki has "Resolution: 0.1". Resolution would be hard to define if the distance is “approximate”. This problem is resolved by calling it “approximate distance” or/and amending the type to String and deleting “resolution”.
- Making it a string type allows encoders to enter more-or-less what they want (see the examples above). This has both advantages and disadvantages.
- With 'approximate distance' position cannot be automatically generated. The counterquestion would be: “Can you always provide a distance in a resolution of 0.1?”. That would be impossible too. And an automatic way to determine the spatial location based on a “bearing information” is rather unlikely.
- Balancing the above points, we think approximate distance should suffice for the complex attribute 'bearing information' (BRGINF) as a part of picture information in GRAPHC. If a use case arises for encoding precise distance in BRGINF the existing 'measured distance' attribute can be added as an optional sub-attribute of BRGINF.
Alternatively, the existing 'measured distance' attribute in the GI registry could be updated so that its definition and type (currently Integer) works for both approximate and measured distances. However, this might complexify other parts of the modeling if people want to distinguish approximate from precise distances.