Jump to content


Photo

Spurious spaces in PUBL text from gedcom import

gedcom import

  • Please log in to reply
5 replies to this topic

#1 spacecat56

spacecat56

    Member

  • Members
  • PipPip
  • 6 posts

Posted 25 July 2017 - 12:24 PM

This is a fragment of gedcom for a source in an export from FTM 2017

 

0 @S876@ SOUR
1 AUTH Ancestry.com
1 TITL 1900 United States Federal Census
1 PUBL Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date: 
2 CONC 2004;
1 REPO @R66@
1 NOTE
2 CONC United States of America, Bureau of the Census, Twelfth Census of the 
2 CONC United States, 1900, Washington, D.C.: National Archives and Records 
2 CONC Administration, 1900
0 @S877@ SOUR
1 AUTH Ancestry.com and The Church of Jesus Christ of Latter-day Saints
1 TITL 1880 United States Federal Census
1 PUBL Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date: 
2 CONC 2010;
1 REPO @R66@
1 NOTE
2 CONC Tenth Census of the United States, 1880. (NARA microfilm publication 
2 CONC T9, 1,454 rolls). Records of the Bureau of the Census, Record Group 
2 CONC 29. National Archives, Washington, D.C.
 
 
and here's what I see in the RM7.5 Source List, and wherever the source is emitted:
 

Footnote: Ancestry.com and The Church of Jesus Christ of Latter-day Saints, 1880 United States Federal Census (Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date: 201 0;)

Short Footnote: Ancestry.com and The Church of Jesus Christ of Latter-day Saints, 1880 United States Federal Census

Bibliography: Ancestry.com and The Church of Jesus Christ of Latter-day Saints. 1880 United States Federal Census. Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date: 201 0;.

Source comments:
Tenth Census of the United States, 1880. (NARA microfilm publication T 9, 1,454 rolls). Records of the Bureau of the Census, Record Group 29 . National Archives, Washington, D.C.

Repository:
www.ancestry.com

 

 

With spurious blank space injected into the "2010".

 

I just retested the import on RM7.5.2.0 , certainly from the file with the data given above, and certainly with the result shown.

 

Bug in RM7.  Yes, a "nuisance" but things like this degrade the quality of the output and make the preparer look careless... not acceptable.

 

 



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6162 posts

Posted 25 July 2017 - 01:49 PM

Also, "T 9".

But the fault lies with Ancestry for violating the GEDCOM standard which specifies that the CONCatenate tag must be mid-word, not at a boundary.

That said, Ancestry has breached the rule for so long that one might reasonably expect RM to cope with it. Without special measures, you would get "twowords" instead of "two words" if there was a CONC immediately after the "two". RM is trying to cope with the Ancestry misbehaviour by inserting a space but is misplacing it, e.g., "twowor ds".

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#3 spacecat56

spacecat56

    Member

  • Members
  • PipPip
  • 6 posts

Posted 25 July 2017 - 02:16 PM

Also, "T 9".

But the fault lies with Ancestry for violating the GEDCOM standard which specifies that the CONCatenate tag must be mid-word, not at a boundary.
...

 

ARRGH!  Red-face mistake!  I had too many files open and I actually pulled tose tags from the wrong file!

 

 

Here's what's actually, really in the gedcom that I imported:

 

0 @S877@ SOUR
1 AUTH Ancestry.com and The Church of Jesus Christ of Latter-day Saints
1 TITL 1880 United States Federal Census
1 PUBL Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date: 201
2 CONC 0;
1 REPO @R66@
1 NOTE
2 CONC Tenth Census of the United States, 1880. (NARA microfilm publication T
2 CONC 9, 1,454 rolls). Records of the Bureau of the Census, Record Group 29
2 CONC . National Archives, Washington, D.C.
 

 

... so the problem seems rather to be, they are assuming mis-use of the CONC tag.



#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6162 posts

Posted 25 July 2017 - 02:46 PM

Yes, it would appear that Ancestry has corrected its behaviour and RM is still compensating for it.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#5 spacecat56

spacecat56

    Member

  • Members
  • PipPip
  • 6 posts

Posted 29 July 2017 - 01:39 PM

Yes, it would appear that Ancestry has corrected its behaviour and RM is still compensating for it.

Not Ancestry any more, FTM was transferred altogether to Software MacKiev.  They released a relatively minor update denoted 2014.1 last year, and major new release called FTM 2017 a few weeks ago. 



#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6162 posts

Posted 29 July 2017 - 03:07 PM

My error. IIRC, both Ancestry and FTM misbehaved that way at one time.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.