|
|
|
|
Customers
FamilyTrees.GenoPro.com
GenoPro version: 3.1.0.1
Last Login: Sunday, May 12, 2024
Posts: 472,
Visits: 3,204
|
When exporting a GenoMap with the Report Generator, the generated code contains several lines reading "3 FORM addr1".
When importing into other tools, these lines are flagged as an errors.
I tested this again with the latest version of the "Export to Gedcom" skin (2.0.1.6-6 2010.01.05) but the lines are still there.
I could simply filter these lines out but I'm not sure about what you are trying to define in the FORM lines. Could you please explain?
|
|
|
|
|
Customers
GenoPro version: 2.5.4.0
Last Login: Sunday, September 20, 2015
Posts: 64,
Visits: 1,814
|
An Address in the form of "Carrowbeg, Tyrone, Nth.Ireland" would generate a tag of "3 FORM addr1,addr2,addr3" when creating a GEDCOM file from Genopro.
1 BIRT
2 PLAC Carrowbeg, Tyrone, Nth.Ireland
3 FORM addr1, addr2, addr3
1 DEAT Y
2 PLAC Cavankilgreen, Tyrone, Nth.Ireland
3 FORM addr1, addr2, addr3
I don't know why it is necessary in Genopro unless it has something to do with sorting.
Like you I have to replace all references to FORM with blank lines when exporting to other programs or online web pages.
I also have to replace DEAT Y with DEAT.
|
|
|
|
|
Customers
FamilyTrees.GenoPro.com
GenoPro version: 3.1.0.1
Last Login: Sunday, May 12, 2024
Posts: 472,
Visits: 3,204
|
According to the GEDCOM standard 5.5 specifications the FORM keyword can be used for any information.FORM {FORMAT} An assigned name given to a consistent format in which information can be conveyed |
I also found it subsequent to a PLAC keyword in the GEDCOM file GenoPro generated but it can be used elsewere like in 1 GEDC
2 VERS 5.5
2 FORM Lineage-Linked |
To me it looks as if the "addr1, addr2, ..." strings were not replaced by their values. I presume Ron will react on this.
|
|
|
|
|
Administrators
Customers
Important Contributors
FamilyTrees.GenoPro.com
GenoPro version: 3.1.0.1
Last Login: 1 hour ago
Posts: 3,348,
Visits: 25,676
|
Just a quick post as I am away in the Canary Islands soaking up the sun at present. Essentially the FORM should be giving the structure of an address or place so that the receiving system can interpret it. I'll look into the problems it is causing on my return to the UK next week.
'lego audio video erro ergo disco' or "I read, I listen, I watch, I make mistakes, therefore I learn"
|
|
|
|
|
Administrators
Customers
Important Contributors
FamilyTrees.GenoPro.com
GenoPro version: 3.1.0.1
Last Login: 1 hour ago
Posts: 3,348,
Visits: 25,676
|
I have a bit more time to look deeper into this issue and reread the Gedcom 5.5 spec. I have concluded that some changes are in order. Firstly with the 'DEAT Y' tag, I discovered that the Y should only be needed when there are no subordinate tags to the DEAT tag (e.g. no date or place of death). It asserts the death when there is no other data. I will change the export to reflect this. Regarding the FORM tag, I concede that it is not much use with just addr1, addr2, addr3 etc. However I believe these tags are valid Gedcom and should not be flagged as errors. Also currently I use the address info when present instead of Place name for the PLAC data at present and no account is taken of any hierarchical Place data. I propose the following changes. If any address data is present then this will be placed in a Gedcom ADDR tag structure, with ADR1 (for street), CITY (for City & County), STAE (for state/region), POST (zip/post code) & CTRY (country) subtags. Note that there is no sub tag for county in Gedcom. For non-heirarchic Places, only a PLAC tag with no FORM sub tag will be generated. For hierarchical Places (those with parent places) the names of the parent places will be cocatenated with the Place name, separated with commas and FORM tag will be added with the Place Category of each parent place. This is more in line with the Gedom spec. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names. Update: These changes are now available in the Latest Export to Gedcom skin
'lego audio video erro ergo disco' or "I read, I listen, I watch, I make mistakes, therefore I learn"
|
|
|
|
|
Customers
Important Contributors
FamilyTrees.GenoPro.com
Translator
GenoPro version: 3.1.0.1
Last Login: Sunday, March 21, 2021
Posts: 716,
Visits: 12,927
|
Receiving following message when using this latest Gedcom export function:
Opening configuration file Config.xml for skin '\Gedcom_2.0.1.6_(2010.02.13)\* (Export to Gedcom)'... Loading Dictionary.xml... [0.00] Processing template 'Gedcom.js'... Error at line 229, position 9 (Code/Utils.js): Exception thrown and not caught Microsoft JScript runtime error 800A139E
What went wrong?
|
|
|
|
|
Administrators
Customers
Important Contributors
FamilyTrees.GenoPro.com
GenoPro version: 3.1.0.1
Last Login: 1 hour ago
Posts: 3,348,
Visits: 25,676
|
maru-san (2/13/2010)
What went wrong? Sorry, I had added a comment to Config.xml after my testing that had & instead of the XML entity & making the xml syntax invalid and causing the error. I have now uploaded a corrected version. A lesson to myself - I must always retest even after the smallest change. 
'lego audio video erro ergo disco' or "I read, I listen, I watch, I make mistakes, therefore I learn"
|