On 11/18/17 12:51 PM, Chris Sackett wrote: > Robin, Michael, John, > > Many thanks for your reassuring remarks about switching in due course from TMG and SS to HRE and GedSite, in particular for explaining that HRE should be able to produce a GEDCOM in a couple of minutes rather than the 48 minutes taken by TMG in my test run. That really is a game changer. > > Regarding the comment that not all data is capable of export to GEDCOM, are there at this stage known TMG features that, although they will transfer directly to HRE, will still not be able to be exported to a GEDCOM file and thus will not be able to be published on a website? In other words, are there clean-up or other tasks I could be doing now in TMG to avoid website problems after switching from a direct TMG-SS system to an indirect HRE-GEDCOM-GedSite system? > > Chris Sackett > There are lots of features in TMG that can not be exported as a 'Standard' GEDCOM. A number of extensions, many/most of which John has put support for in GEDSITE are available in some programs to record in the extended GEDCOM much of this information. I suspect that there are still some features of TMG that haven't had an extension to support them, largely because no other program supports all the features of TMG, and thus no other program needed to implement an extension to GEDCOM to express it, and for the most part, TMG didn't worry about extending GEDCOM to maximize the information it exported, but instead until near the end focused on producing a total standard GEDCOM expressing the information that GEDCOM was designed for, and at the end added the option to include a number of the common extensions that other programs used to express their feature that standard GEDCOM couldn't handle. This doesn't mean that HRE couldn't work on creating further extensions to express more of these features, and John could support them in GEDSITE. (I would hope that they could work together to maximize the information transfer). That said, while creating a GEDCOM to express the basic, and even some of the advanced, genealogical data/features is probably on the road map for HRE, even more than TMG, they are not constraining the data model to be easily expressible as a GEDCOM, even with significant extensions. For example, I am not sure how badly you would need to abuse the GEDCOM standard to handle the fact that HRE treats places differently than the GEDCOM standard, allowing a lot of descriptive information to be attached and interrelatons recorded (a place may have multiple names, perhaps with time periods assigned; may be part of larger entities, again possibly with time periods; be divided into multiple sub-places, been derived from and later become other places over time, etc). -- Richard Damon

Hi Richard, You are right to point out that an HRE export to GEDCOM can only be expanded to data that GEDCOM has a concept for. Because of this there is an inherent limit on what could be exported to a GEDCOM file. That export has no benefit if there is no application that can import and use that data. Our prime requirement is to migrate TMG data into HRE without loss of meaning or functionality. This includes being able to export to GEDCOM from HRE all the data elements that TMG can currently export. As to the comparative speed of HRE and TMG, there are 2 technology advantages that HRE has over TMG. Because of the limitations of the Visual FoxPro database used within TMG, much of the TMG data has to be held in separate VFP memo files. There are a lot of opening and closing of files in TMG. Secondly when TMG was being built the amount of application memory was tiny so very little data could be saved in memory for reuse (cached). The H2 database engine internal to HRE has larger capacity string field types that are stored with the other data. HRE operates as a single project file removing the ongoing establishment of multiple file accesses. In today's computers there is more opportunity to save frequently used data to memory as do many modern genealogical applications. This is not a 1:1 comparison as HRE stores its data in a different structure so until tested the actual difference in speed can only be conjectured. Robin On 19-Nov-17 05:20 AM, Richard Damon wrote: > On 11/18/17 12:51 PM, Chris Sackett wrote: >> Robin, Michael, John, >> >> Many thanks for your reassuring remarks about switching in due course >> from TMG and SS to HRE and GedSite, in particular for explaining that >> HRE should be able to produce a GEDCOM in a couple of minutes rather >> than the 48 minutes taken by TMG in my test run. That really is a >> game changer. >> >> Regarding the comment that not all data is capable of export to >> GEDCOM, are there at this stage known TMG features that, although >> they will transfer directly to HRE, will still not be able to be >> exported to a GEDCOM file and thus will not be able to be published >> on a website? In other words, are there clean-up or other tasks I >> could be doing now in TMG to avoid website problems after switching >> from a direct TMG-SS system to an indirect HRE-GEDCOM-GedSite system? >> >> Chris Sackett >> > There are lots of features in TMG that can not be exported as a > 'Standard' GEDCOM. A number of extensions, many/most of which John has > put support for in GEDSITE are available in some programs to record in > the extended GEDCOM much of this information. I suspect that there are > still some features of TMG that haven't had an extension to support > them, largely because no other program supports all the features of > TMG, and thus no other program needed to implement an extension to > GEDCOM to express it, and for the most part, TMG didn't worry about > extending GEDCOM to maximize the information it exported, but instead > until near the end focused on producing a total standard GEDCOM > expressing the information that GEDCOM was designed for, and at the > end added the option to include a number of the common extensions that > other programs used to express their feature that standard GEDCOM > couldn't handle. > > This doesn't mean that HRE couldn't work on creating further > extensions to express more of these features, and John could support > them in GEDSITE. (I would hope that they could work together to > maximize the information transfer). > > That said, while creating a GEDCOM to express the basic, and even some > of the advanced, genealogical data/features is probably on the road > map for HRE, even more than TMG, they are not constraining the data > model to be easily expressible as a GEDCOM, even with significant > extensions. For example, I am not sure how badly you would need to > abuse the GEDCOM standard to handle the fact that HRE treats places > differently than the GEDCOM standard, allowing a lot of descriptive > information to be attached and interrelatons recorded (a place may > have multiple names, perhaps with time periods assigned; may be part > of larger entities, again possibly with time periods; be divided into > multiple sub-places, been derived from and later become other places > over time, etc). > -- Robin Lamacraft, Adelaide, Australia