Talk:GRAPHC

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.

jens 06:12, 20 March 2012 (UTC) spoken with our TSMAD rep. It seems they haven't done detailed work on that. We can go ahead.

jens 11:05, 3 May 2012 (UTC) Thought about this for a while. My response on Raphael's 01:27, 19 March 2012 (UTC) discussion:

1. sounds good
2. MMGRUP as information object sounds fine too. I have problems with the association. Actually we have modelled GRAPHC as complex attribute. I consider it very hard to determine the relevant geographic features where the MMGRP can be associated to.
3. is there a way to specify them more general. You know, today we have mpeg4 or whatever, tomorrow complete new formats.
4. I don't know. I have not enough expertise. That should be discussed with TSMAD, may be?

DavidAcland 11:04, 8 May 2012 (UTC) A few thoughts.

I have noticed that the camera on my telephone provides a GPS position in the exif data. Very interesting. So increasingly we are going to be able to receive this data in the digital image. As image reading software matures the exif data will be read routinely.

This will be a very useful geographic source but we probably want to be able to encode it as well. Would this be a geographic feature? Photograh? Picture? CameraPosition in its own right? If we went down this route I can see an attribute like:

Category of camera position:

1= GPS;

2= derived from cellphone information;

3= Derived from image;

I will send you a link to the views I took in Stavanger plus the position metadata from the camera. I then overlayed that on the chart and may still have that file. If so I will send that as well.

Where we do not have camera position, we should be able to encode the subject position probably as a point or oval plus bearing information - another use case for fuzzy geography. The Panoramio solution on Google Earth goes a long way but does not capture the direction aspect which I think is important in our business. Is this another feature? ViewSubject? PhotographSubject? ImageSubject? and its cousin VideoSubject? or the generic MultiMediaSubject?

I think pictureInformation is a bit vague. We already have SORDAT and SORINF which is granular and precise. I am not sure we want to control what is seen round the image but I think the credit or acknowledgement is important and probably different to SORINF. It is a well understood concept so I think I would suggest something like: pictureCredit or imageCredit and the ECDIS could be allowed to define the resolution of the date. Could we somehow say: Provide date as a minimum resolution to the year; month and date optional?

jens 09:29, 9 May 2012 (UTC) Camera position: I guess, we start to overestimate the importance of the camera position accuracy.
My proposal:
1. derived using radio navigation position,
2. derived from exif
3. estimated by deriving from image

raphael 04:59, 14 May 2012 (UTC): Would not the geographic features with which the image is associated in the dataset denote the subject? Additional information if any would presumably be placed in the caption.

Dates: Let's wait a while and see what TSMAD do with dates and times.

Jens, could you explain item 3 in your proposal?

I think the camera location is useful mainly as a proxy for the location of the subject, so its usefulness will vary.

jens 04:59, 15 May 2012 (UTC) Raphael, Regarding item 3:
I think, if 1 and 2 are not available one can (hopefully) obtain from the picture where the location of the camera was. That can only be an approximate position but better than nothing. Means, the first two items can be positions and the third item can be a string if a psn can't be specified.

raphael 05:30, 15 May 2012 (UTC): OK

raphael (talk) 00:25, 4 February 2017 (CET): proposed definition: Pictorial information such as a photograph, sketch, or other graphic, optionally accompanied by descriptive information about the graphic and the location relative to its subject from which it was made.
Q: 'descriptive information' or 'metadata'? metadata fits but there is very little of it and it is quite informal - far from what ISO or S-100 would regard as metadata.