I have a GEDCOM originally generated via RootsMagic 4.0.7.1. When it is imported into a PhpGedView database, the GEDCOM validation step reports everything essentially normal. The only issue is a warning about impending cleanup of a byte order mark. But after successful import, some invalid GEDCOM tag errors appear, e.g. invalid level 1 _PROOF records, etc. To see if I could clean these distractions up, I edited the GEDCOM in Notepad to rempve the _PROOF record associated with a level 1 PROP record and re-imported it. The releveant subrecord nest appears below as it exists before the edit. The edit consists simply of deleting the "2 _PROOF proven" subrecord.
1 PROP
2 _PROOF proven
2 DATE 26 JAN 1876
2 PLAC Faison's Old Tavern, Wiccacanee Twp., Northampton Co., NC, USA
2 SOUR @S2101@
The resulting GEDCOM import validation pass reports "Invalid place encodings were detected. These errors should be fixed."
Example of invalid place from your GEDCOM:
1 PROP
2 DATE 26 JAN 1876
2 PLAC Faison's Old Tavern, Wiccacanee Twp., Northampton Co., NC, USA
I do not see any invalid tag error here. Can someone help? Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PROP tag is not supposed to be empty, so you should have "1 PROP four horses", etc.
Now, one of the popular desktop applications stores the value of these fields in the PLAC field. e.g.
1PROP2PLACfourhorses
So, if you have an empty PROP (and certain other tags too), and data in the place, PGV tries to correct this by moving the PLAC value to the PROP value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I let PhpGedView do its proposed cleanup on the import and the result is to move the PLAC record value field to the value field of the PROP record, as yuu described. It appears the cleanup works fine. I was just alarmed by the error report.
Thanks for the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I now have related validation issue associated with RootsMagic 4 GEDCOMs. When I import, after getting past BOM and PROP cleanup, the import proceeds to completion but just before it reports import statistics, it issues an "Invalid Gedcom Format" warning. It is not clear to me whether this is due to the PROP record cleanup or whether it is due to some other unspecified problem encountered during the import. Assuming it is the latter, a possible source of the problem is the way RM4 catalogs places with NOTEs, MAPs, OBJEs, etc. Places with such additional subrecords get collected into a table of "0 _PLAC xxx" records with the amplifying stuff as subordinate records, and that may be taking some liberties with the spec. In any case, I would sure like to know what is happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After the "Invalid Gedcom" message, PGV should display the actual gedcom. Does it? Maybe it is displaying an empty record. (Do you have empty records?).
If you can't work it out, send me the gedcom (fisharebest at gmail dot com), and I'll take a look.
Greg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After an initial go-round, It has begun stringing out a list of "0 _PLAC xxx" record nests following the import stats report. I have no idea why it did not do so on the first try. An example is -
0 _PLAC AK, USA
1 MAP
2 LATI N61.3850000
2 LONG W152.2683000
1 OBJE
2 FILE \places\USA\flags\AK.gif
2 FORM gif
2 TITL Flag - Alaska
2 _TYPE PHOTO
2 _SCBK Y
2 _PRIM Y
I think that what happens is the PGV validation does not accept the level 0 _PLAC records.
Also, back to the invalid PROP record cleanup, I have other examples in my RM4 database which have "Description" fields (in RM4) and the corresponding values get entered as value field for the PROP record in the RM4 generated GEDCOM. Thus, after PGV cleanup, I end up with a mix of such description values and transplanted PLAC values, and this is screwing up my GoogleMap displays. That is, the PROP records which have a RM4 non-place value generate GoogleMap display errors. I have examined the GEDCOM spec (at least something I found online) and it admits "Event Detail" structures subordinate to PROP records and the event detail structure admits PLAC records.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is PGV's way of telling you that it doesn't recognise these "0 _PLAC" records. PGV ignores them, and they will be lost on any subsequent download/export.
Search the forum archives for much discussion about level 0 place objects……
<<Also, back to the invalid PROP record cleanup>>
RM4 doesn't generate these invalid records, then say NO to this particular cleanup option. It is only intended for gedcoms generated by desktop apps (IIRC FTM) that wrongly put the record value in the place field.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. I can ignore PROP cleanup warnings and discarding the RM4 0 _PLAC record nests doesn't matter either. I import my place hierarchy data from an external file. But just to clarify, when building event GoogleMaps, does PGV use the PROP value field for the place name information or does it use the value field of a subordinate PLAC record.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a GEDCOM originally generated via RootsMagic 4.0.7.1. When it is imported into a PhpGedView database, the GEDCOM validation step reports everything essentially normal. The only issue is a warning about impending cleanup of a byte order mark. But after successful import, some invalid GEDCOM tag errors appear, e.g. invalid level 1 _PROOF records, etc. To see if I could clean these distractions up, I edited the GEDCOM in Notepad to rempve the _PROOF record associated with a level 1 PROP record and re-imported it. The releveant subrecord nest appears below as it exists before the edit. The edit consists simply of deleting the "2 _PROOF proven" subrecord.
1 PROP
2 _PROOF proven
2 DATE 26 JAN 1876
2 PLAC Faison's Old Tavern, Wiccacanee Twp., Northampton Co., NC, USA
2 SOUR @S2101@
The resulting GEDCOM import validation pass reports "Invalid place encodings were detected. These errors should be fixed."
Example of invalid place from your GEDCOM:
1 PROP
2 DATE 26 JAN 1876
2 PLAC Faison's Old Tavern, Wiccacanee Twp., Northampton Co., NC, USA
I do not see any invalid tag error here. Can someone help? Thanks.
I don't see anything wrong here, except possibly the apostrophe (which shouldn't be a problem).
Why not let the Import do its "correction" thing, and then look at that particular record to see what it's done?
The PROP tag is not supposed to be empty, so you should have "1 PROP four horses", etc.
Now, one of the popular desktop applications stores the value of these fields in the PLAC field. e.g.
So, if you have an empty PROP (and certain other tags too), and data in the place, PGV tries to correct this by moving the PLAC value to the PROP value.
I let PhpGedView do its proposed cleanup on the import and the result is to move the PLAC record value field to the value field of the PROP record, as yuu described. It appears the cleanup works fine. I was just alarmed by the error report.
Thanks for the help.
I now have related validation issue associated with RootsMagic 4 GEDCOMs. When I import, after getting past BOM and PROP cleanup, the import proceeds to completion but just before it reports import statistics, it issues an "Invalid Gedcom Format" warning. It is not clear to me whether this is due to the PROP record cleanup or whether it is due to some other unspecified problem encountered during the import. Assuming it is the latter, a possible source of the problem is the way RM4 catalogs places with NOTEs, MAPs, OBJEs, etc. Places with such additional subrecords get collected into a table of "0 _PLAC xxx" records with the amplifying stuff as subordinate records, and that may be taking some liberties with the spec. In any case, I would sure like to know what is happening.
After the "Invalid Gedcom" message, PGV should display the actual gedcom. Does it? Maybe it is displaying an empty record. (Do you have empty records?).
If you can't work it out, send me the gedcom (fisharebest at gmail dot com), and I'll take a look.
Greg
After an initial go-round, It has begun stringing out a list of "0 _PLAC xxx" record nests following the import stats report. I have no idea why it did not do so on the first try. An example is -
0 _PLAC AK, USA
1 MAP
2 LATI N61.3850000
2 LONG W152.2683000
1 OBJE
2 FILE \places\USA\flags\AK.gif
2 FORM gif
2 TITL Flag - Alaska
2 _TYPE PHOTO
2 _SCBK Y
2 _PRIM Y
I think that what happens is the PGV validation does not accept the level 0 _PLAC records.
Also, back to the invalid PROP record cleanup, I have other examples in my RM4 database which have "Description" fields (in RM4) and the corresponding values get entered as value field for the PROP record in the RM4 generated GEDCOM. Thus, after PGV cleanup, I end up with a mix of such description values and transplanted PLAC values, and this is screwing up my GoogleMap displays. That is, the PROP records which have a RM4 non-place value generate GoogleMap display errors. I have examined the GEDCOM spec (at least something I found online) and it admits "Event Detail" structures subordinate to PROP records and the event detail structure admits PLAC records.
This is PGV's way of telling you that it doesn't recognise these "0 _PLAC" records. PGV ignores them, and they will be lost on any subsequent download/export.
Search the forum archives for much discussion about level 0 place objects……
<<Also, back to the invalid PROP record cleanup>>
RM4 doesn't generate these invalid records, then say NO to this particular cleanup option. It is only intended for gedcoms generated by desktop apps (IIRC FTM) that wrongly put the record value in the place field.
OK. I can ignore PROP cleanup warnings and discarding the RM4 0 _PLAC record nests doesn't matter either. I import my place hierarchy data from an external file. But just to clarify, when building event GoogleMaps, does PGV use the PROP value field for the place name information or does it use the value field of a subordinate PLAC record.
PGV (and googlemap) just use the PLAC field.