John, Dennis, et al, I will not be adapting Second Site to work with HRE. As mentioned in this thread, Second Site reads the TMG database directly and it's not practical to adapt it to the HRE database format for several reasons. My GedSite program processes GEDCOM files. It has a very flexible GEDCOM reader that adapts to the differences between GEDCOM files produced by many software programs. Here are some examples where GedSite handles non-standard GEDCOM constructs: - GedSite loads witnesses and roles from several programs. - GedSite loads sentence templates from RootsMagic, Family Historian, and Legacy, and interprets them according to the rules of the source program. (GedSite uses its own sentence templates for other programs that do not have them or do not export them via GEDCOM.) - GedSite loads flags from Family Historian and Brother's Keeper, and users can use those flags in filters. - And many, many, more. If you go to http://www.gedsite.com/en/contents.htm and look under "GEDCOM Source Applications", you'll see a list of source programs. Click an entry to see how GedSite handles GEDCOM files from the application. While GedSite is intended primarily for use with GEDCOM, it's possible to adapt it to other data formats. However, I think it is unlikely I will adapt it to read an HRE database directly. There are several issues involved and I think it makes more sense for HRE to export a GEDCOM file. When an HRE GEDCOM export is available, I'll configure GedSite to load it. John

John Cardinal wrote: > When an HRE GEDCOM export is available, > I'll configure GedSite to load it. I agree with John that this approach makes the most sense. I have often stated that the official GEDCOM standard is extremely out of date and unable to handle modern features in genealogy programs like TMG and others. But that standard does define a "standard" way for a program to include its own "non-standard" GEDCOM data structures in a GEDCOM file. The final version of TMG has an optional advanced GEDCOM export which uses this method to output many of the advanced TMG features which cannot be described in standard GEDCOM, such as witnesses and sort dates. As John mentioned, several other modern genealogy programs also output their own advanced features using their own choices of non-standard GEDCOM data. John has cleverly designed GedSite to allow the user to specify *which* program produced this GEDCOM file. If that program is in GedSite's list, the program then can recognize that program's specific non-standard GEDCOM data and make use of that data in creating the web pages. So once HRE decides on how it chooses to export its advanced features in its own version of non-standard GEDCOM data structures, John will be able adapt GedSite to recognize those unique HRE structures. Many of us look forward eagerly to an HRE which exports it own non-standard GEDCOM data which an adapted GedSite can then recognize. Michael

On 16 Nov 2017, at 16:02, John Cardinal <[email protected]> wrote: > > I will not be adapting Second Site to work with HRE. As mentioned in this > thread, Second Site reads the TMG database directly and it's not practical > to adapt it to the HRE database format for several reasons. > ... > While GedSite is intended primarily for use with GEDCOM, it's possible to > adapt it to other data formats. However, I think it is unlikely I will adapt > it to read an HRE database directly. There are several issues involved and I > think it makes more sense for HRE to export a GEDCOM file. When an HRE > GEDCOM export is available, I'll configure GedSite to load it. I’m getting a bit confused, and a bit worried, about what I might need to do about TMG, SS, and HRE. The most important thing I do with my genealogy is publish a website, using SS output from TMG. I am constantly adding to my database and I update the website at least once a month with a complete upload of the whole site to FHH. I have not looked in detail at GedSite as it was clearly stated that SS is the better option for TMG. After reading the current thread, out of interest, I exported a GEDCOM from TMG. It took 48 minutes. I don’t know how long it might take with HRE but, however long it is, this is going to be a significant extra step every time I update my website. I always review changes in a local version before uploading, and I always find changes/corrections I need to do. This is not that big a deal when it takes about 7 minutes to re-make the site. But it will become a serious PITA if I have to export to GEDCOM every time as well. The possibility is mooted of HRE having its own website generator. Perhaps it’s too early to ask, or to know, but is this likely to have all the goodies we’ve been used to with SS? My fear is that I’ll be faced with the dilemma of sticking with TMG, which is running out of time, in order to continue taking advantage of SS features, or switching to a future-proof HRE, but in the process either losing a bunch of brilliant features or having to go through the additional hassle of making repeated GEDCOM files. Chris Sackett

Chris Sackett wrote: > I’m getting a bit confused, and a bit worried, about what I might > need to do about TMG, SS, and HRE. Chris, Let me try to ease your worries and confusion. I think you are anticipating this to be much more difficult than I think it will be. First, staying with TMG and SS for the time being I believe is a good thing, and will remain extremely viable for many *years* to come. Second, if (when?) you choose to transition I believe the best action will be to replace both TMG and SS at the same time with HRE and GedSite respectively. Robin has indicated that HRE will directly import your TMG databases. While there may be some "clean-up" to take advantage of new features in HRE, I suspect the conversion will be relatively painless since that direct import is a design goal of HRE. Next, you will export from HRE (not from TMG) to GEDCOM. The TMG GEDCOM export is limited in features. HRE is expected to be able to output many more features of its database into GEDCOM than TMG does using special non-standard GEDCOM constructs. Thus I expect that the HRE GEDCOM will be more complete than what TMG can produce. Finally, John has indicated he will enhance GedSite to recognize these HRE GEDCOM constructs to make web sites. Remember what little you needed to do to create your first Second Site web pages? The same simplicity is already available in GedSite, and I trust John that it will be just as simple when the input is a future HRE GEDCOM file. So I recommend sticking with TMG and SS for now, and not bothering with GEDCOM from TMG. But when they become available I believe you can expect to have an easy transition to HRE and GedSite later, and will gain added capabilities from those even more modern programs. Take a deep breath. Thanks to Robin and John I believe they will make sure there is not a problem here. Have faith! Michael