* Place for a photo

[IanHiggs]

I am adding a lot of photos and would like to record a 'Place' where the photo was taken. I could include this in the Notes field, but that would just be free text and would not result in a reference in the Places lists etc.

Can anybody suggest a way around this?

ID:3316

[Jane]

There is a wish list item for adding media to places, to search photographs for places if you label the text in the notes you could use the GetLabelledText function to search for photograph locations, or just use the containstext function to search the notes for a location.

[IanHiggs]

Thanks Jane.

I have been digging deeper into this and think that there is a bug in FH.

The GEDCOM 5.5 spec defines a MULTIMEDIA_RECORD as
 n @@ OBJE  {1:1}
   ...
   +1 >  {0:M}
   ...

i.e. it may include sources.

The context menu in FH allows for a single Date to be added to a Multimedia object, but no Sources. (The date is recorded as the custom field: _DATE.)

This boils down to 2 requests then:

Bug fix:
Allow a Multimedia object to include Sources as defined in GEDCOM 5.5.

Is there a more formal way to report bugs? (This is Wish List #310, but is this already reported as a bug?)

Wish list:
Allow a Multimedia object to include a _PLACE custom field.

I cannot find something like it already in the list - Wish List #8 and #249 are the inverse: add a Multimedia object to a Place.

[SimonOrde]

Ian - I think you must be looking at the spec for DRAFT Release 5.5.1.  In this spec, Multimedia records do have source citations.  However, 5.5.1 was only ever released as a draft - it was never adopted.  The last official release of GEDCOM is version 5.5, and in that version Multimedia records do not have source citations.

[nsw]

That's quite interesting. The site I use for the Gedcom 5.5 standard is:

http://homepages.rootsweb.ancestry.com/ ... enweb.html

and on there it does show a Source Citation for Multimedia Objects. However, on the following version which appears to be a PDF of the official release it doesn't:

http://www.math.clemson.edu/~rsimms/gen ... dcom55.pdf

(There is another HTML version of it here which again doesn't show the Multimedia citation:
http://www.vjet.f2s.com/ftree/gedcom_5. ... edcom.html)

The first link is just an unofficial html version of the official document so this certainly has acted as a warning to me to not fully trust that version, even though it is the first one that comes up in Google.

[JonAxtell]

Simon, could I ask why you are sticking so ridgedly with Gedcom 5.5 and not allowing any 5.5.1 support at all. Is it because 5.5.1 is still a 'draft' - 9 years after it was published. I assume you know that the LDS have officially announced that they have stopped all work on Gedcom so the draft will NEVER become official (see http://www.ancestry.com/learn/library/a ... ticle=3438). You do also realise that many genealogy packages support 5.5.1?

By sticking with Gedcom 5.5 I believe that you are hindering the development of FH. Sticking with a standard (designed mainly for the communication of family information to the LDS and not for genealogical research) that is out of date and will never by updated you are limiting the features that could be included in FH to make it an even better program. Certain user requested features can never be implemented in 5.5, however 5.5.1 allows them. Just a simple thing like implementing an export function which exported either in 5.5 or 5.5.1 will still allow the sharing of Gedcoms with few programs that still use 5.5, though there are many that have 'adopted' 5.5.1. An export routine will also allow you to implement other features using gedcom extensions that could be stripped out to support 5.5 or 5.5.1

I do also have to state that gedcom is used for sharing conclusional genealogical information, whilst a genealogy researcher carries out a lot of research that requires noting down assumptions and assertions even negative information. These aren't easily transferred to gedcom. So you are also limiting what a genealogy researcher normally does just to support the now old standard of Gedcom.

*Added*
I know this isn't a thread about Gedcom, but could you also clarify why FH is advertised as 100% support when it has known issues such as multiple 'text from source''s in the source record when only 1 is allowed.

[IanHiggs]

The 'Simms' GEDCOM 5.5 specification (from http://www.math.clemson.edu/~simms/gene ... dcom55.pdf) is dated 'January 2, 1995' and defines a Multimedia object as

n @XREF:OBJE@ OBJE {1:1}
 +1 FORM {1:1}
 +1 TITL {0:1}
 +1 > {0:M}
 +1 BLOB {1:1}
   +2 CONT {1:M}
 +1 OBJE @@ {0:1}
 +1 REFN {0:M}
   +2 TYPE {0:1}
 +1 RIN {0:1}
 +1 >

The 'McBride' GEDCOM 5.5 specification (from http://homepages.rootsweb.ancestry.com/ ... 5gcch2.htm) is dated '2 January 1996 [Revised  10 January 1996]' and defines a Multimedia object as

n @@ OBJE {1:1}
 +1 FORM {1:1}
 +1 TITL {0:1}
 +1 > {0:M}
 +1 > {0:M}
 +1 BLOB {1:1}
   +2 CONT {1:M}
 +1 OBJE @@ {0:1}
 +1 REFN {0:M}
   +2 TYPE {0:1}
 +1 RIN {0:1}
 +1 > {0:1}

i.e. Somewhere in the extra 8 days, somebody added Source references.

However, I can find no reference to where this came from or how 'official' it is.

FH seems to assume that the 2 January version is the real one - although it does (pragmatically) treat a Blob as optional if replaced by a file reference (much like the 5.5.1 drafts).

So my Wish list request becomes:

Allow a Multimedia object to include a _PLACE custom field and a _SOURCE custom field.

[gerrynuk]

JonAxtell said:
Simon, could I ask why you are sticking so ridgedly with Gedcom 5.5 and not allowing any 5.5.1 support at all.
>

Jon,

Shouldn't you wait until the spec for v4 is published before launching into criticism? Or do you know something the rest of us don't?

Gerry

[JonAxtell]

Ian,
The official spec (available from familysearch.org in Envoy format) is dated 2 Jan 1995, though I suspect that this is an error and should be 2 Jan 1996 because the document states that it follows the release of a version on 11 Dec 1995. There is no mention of an errata list which is dated the 10th. Therefore to use Simon's arguments the version dated the 10th is not official. However I suspect that because the LDS have given up on Gedcom, that the errata note wasn't widely published enough to get included in the versions of the spec currently floating around the net.

Gerry,
There is no mention of any change in support level of Gedcom in the v4 announcement. Also from Simon's previous messages here on this forum and on the FH mailing list about Gedcom issues and feature requests I get the impression (rightly or wrongly) that he is fixated on Gedcom 5.5 and will not budge. This is probably related to the statement that FH is 100% Gedcom complete and compatible, see http://www.family-historian.co.uk/features/index.htm. If he switched to 5.5.1 then he is not using the official version and so is not following the official standard and so cannot make the claim about full Gedcom support. Though this hasn't stopped many other genealogy programs from claiming support for Gedcom and including 5.5.1 in their level of support. I would add that for other genealogy programs the level of support is not too much of an issue since it's only during import/export that its an issue and not something that they base their whole program around.

[nsw]

In defence of Calico/Simon and his 'fixation' with 5.5, he has been prepared to add extension tags, e.g. for flags, which does extend the standard.

[gerrynuk]

JonAxtell said:
Gerry,
There is no mention of any change in support level of Gedcom in the v4 announcement. Also from Simon's previous messages here on this forum and on the FH mailing list about Gedcom issues and feature requests I get the impression (rightly or wrongly) that he is fixated on Gedcom 5.5 and will not budge. If he switched to 5.5.1 then he is not using the official version and so is not following the official standard and so cannot make the claim about full Gedcom support. Though this hasn't stopped many other genealogy programs from claiming support for Gedcom and including 5.5.1 in their level of support. I would add that for other genealogy programs the level of support is not too much of an issue since it's only during import/export that its an issue and not something that they base their whole program around.

Jon,

I actually agree with you that it is probably time to move on from Gedcom 5.5, perhaps creating a new standard that could be adopted by other programs. At the same time, it would still be useful to have the option to export in Gedcom 5.5 standard - perhaps the ability to export in other formats as well.

Gerry

[JonAxtell]

I should have added that when it comes to exporting (something which FH lacks*) all programs allow the user to specify the type of export to some degree - Gedcom 5, 5.5.1 or some other format for exchange between identical programs.

*YES I do know it's not necessary because the data is already Gedcom but not everyone wants to give their Gedcom warts and all to other researchers and the STHF is not user friendly. Carrying out tasks such as removing FH extensions or moving FH extensions into notes are somethings that could be done in an export routine so that it doesn't become such an issue that FH does not follow the 5.5spec to the letter.

[ChrisBowyer]

I rather agree with you Jon... I've always kept out of arguments about what constitutes a 'standard' Gedcom. It makes no difference to me how FH stores the data as long as it supports the functionality I need. I'm always going to do some kind of 'export' operation before I give my data to anyone else, either by split tree, report, generate a website, or whatever.

[RalfofAmber]

Agreed with both Chris and Jon, as long as the program interfaces to a standard that is the main thing for most uses. I know some packages worry about doing better imports when taking files from others and a lot of work can be lost if you move around, but I think we understand that in the main.

[ADC65]

I disagree, and quite frankly I wish people would stop trying to get FH changed from the way it currently works. If you aren't happy with that, it might be time to move onto another piece of software that does meet your needs rather than constantly sniping at the one thing that some users actually want - 100% compliance.

If you allow the program to break the 5.5 standard, for example by allowing Multimedia to have source citations, then this data cannot be output in a GEDCOM 5.5-compliant file. This means the data cannot be imported safely into other applications.

[RalfofAmber]

Adrian,

I think we are saying that 5.5 compliance is a minimum standard and some of us would like to go beyond it. If a feature X existed but was marked as 'Use this and the gedcom piece is not 5.5 compliant' then those that want full compatibility can choose not to use it.

We clearly all rate FH highly but I suspect that there is no perfect piece of software nor one that suits all users all of the time. I for one am trying to understand what might support my limited ability to do research / documentation within the confines of a very good piece of software.

As to import / export I have never imported anything from anywhere that doesn't have problems / odd tags and so so forth.

[IanHiggs]

 
   Tag not balanced: rant
 

[ADC65]

[grin] @ Ian!

Tony, I agree with you in trying to get the most out of FH, we all want that for sure. Re-reading my post it reads as if I wanted everything to remain static - which isn't the case - I just want the unique feature - 100% GEDCOM 5.5 compliance - left alone. I understand this is a selfish attitude!

[IanHiggs]

I think that FH is excellent software and find the overall design and facilities suit me very well.

It is also important that such software can transfer data to other people using a different package and likewise accept data from other packages. For this we need a common standard. GEDCOM does this for us and it is important that software accepts and emits valid GEDCOM data.

However, the current GEDCOM specification is more than a decade old and it seems unlikely that there will ever be a GEDCOM version 6.

While compatibility with a common standard is vital, it should not limit the growth of a package. I started this thread because I wanted to record a place/source for photos and found that I couldn't do it cleanly. (I am still after any advice that helps me do this.) It seems reasonable to ask that FH change to allow this - it is in keeping with the ethos of the standard even if it is not compatible with the letter of the standard. To change this way will not 'break the 5.5 standard' - a file export can still be 100% compliant - but it would allow me to record my sources.

[nsw]

It can still be Gedcom 5.5 but have various custom tags (as there already are) to add functionality being asked for. I think the danger is that the more custom tags there are the more likely that important data will be missing when the GEDCOM is imported into other software as they will almost certainly strip out those custom tags unless they've been written to cater for the Family Historian flavour of GEDCOM 5.5 (like my census app for example).

[IanHiggs]

All true.

The only 'correct' solution to all this is a 'child of GEDCOM' standard that builds on GEDCOM 5.5 to take into account the needs of the current users and software.

Of course, building a consensus about what 'child of GEDCOM' should be is non-trivial and is left as an exercise for the reader...