Difference between revisions of "Talk:GRAPHC"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
Line 35: Line 35:
  
 
[[User:Jens|jens]] 07:06, 19 March 2012 (UTC) I like the multimedia idea and will check with our TSMAD representative what their approach to this issue is. It seems to me that problem should be solved for charted information too and I don't like to do the work twice.
 
[[User:Jens|jens]] 07:06, 19 March 2012 (UTC) I like the multimedia idea and will check with our TSMAD representative what their approach to this issue is. It seems to me that problem should be solved for charted information too and I don't like to do the work twice.
 +
 +
[[User:Rmm|raphael]] 21:41, 19 March 2012 (UTC): Coordinating this with TSMAD is fine, but I think this is one place where Publications needs a more detailed model than ENCs.

Revision as of 21:41, 19 March 2012

jens 09:31, 22 February 2012 (UTC) It was discussed at SNPWG14 to add an information of, tja hard to decribe, well, if the photgraph was made from sea level or from aircraft.
How should we name that? Elevation of camera with two values: shipborn and aircraft? I have no better idea at the moment.

raphael 20:46, 22 February 2012 (UTC): Viewpoint? Camera viewpoint? (Definition: The location of the camera from which a photograph was taken.)
Allowed values:
"surface" or "surface vesssel" or "sea level": Photograph was taken with a camera near sea level.
"aerial": Photograph was taken from an aircraft or balloon.
"satellite": Satellite imagery.

jens 13:27, 28 February 2012 (UTC)
horizontal
low obligue
high oblique
vertical

jens 13:30, 2 March 2012 (UTC) discussed by phone, I guess it can easily be seen from the photgraph provided wether if was taken from vertical or an oblique position. Do we really have to provide this particular information?

raphael 22:12, 13 March 2012 (UTC):

  1. I don't know the answer to your question, Jens.
  2. On another point, I think the multiplicity of PICREP should be either 1 or 1..* instead of 0..1, unless there are circumstances where other sub-attributes would have values but there is no picture file?
  3. What do we do about picture groups, e.g., if there is photo (a) and photo (b), and perhaps a caption for the group as a whole? Shall we define a new complex atribute for the group?

The more I think about it, the more it seems that modeling graphics has enough complexity to become a new information type, especially if we think about defining a model for other media types like video.

jens 10:10, 15 March 2012 (UTC) Thanks for pointing me an the PICREP issue. I have amended it accordingly considered your idea of providing picture groups. You are correct, I remember that we provided those groups in the past.
I have thought about my question and my solution is pragmatic, if a attribute is saying something which is obvious than the attribute is useless. My daughter would say it is a pleonasm using two media. So, I suggest deletion of that information.


Picking up your information type suggestion; do we need to extend what we actually have modeled or should we try to model an information type object using our attributes (may be complex attributes in the future)?

raphael 01:27, 19 March 2012 (UTC): Several different points, below.

  1. Try to model an information type, I think.
  2. Concerning groups, would defining another information object Multimedia Group (MMGRUP) which is associated with the individual GRAPHC objects do? Suggested MMGRUP Attributes: Caption [0..1 or 1?]; SORDAT [0..1]; SORIND [0..1]; PICINF[0..1]
  3. Thinking ahead, what about either generalising GRAPHC and MMGRUP(?) to other media (e.g., audio, video or defining similar types for other media?
  4. About pictures/images specifically, would additional attributes size (X, Y in pixels?) and optimal display size (X, Y in mm) be useful?

jens 07:06, 19 March 2012 (UTC) I like the multimedia idea and will check with our TSMAD representative what their approach to this issue is. It seems to me that problem should be solved for charted information too and I don't like to do the work twice.

raphael 21:41, 19 March 2012 (UTC): Coordinating this with TSMAD is fine, but I think this is one place where Publications needs a more detailed model than ENCs.