Gedcom files that are posted on sites which check for DNA matches only require birth/marriage/death information. Right now RM adds all events to a gedcom. I'd like to see a filter that allows the user to select which events to include in the gedcom export, or at the very least, an option to select BMD events only.
Event filter for GEDCOM export
Posted 12 October 2017 - 11:52 AM
Posted 12 October 2017 - 12:08 PM
If such custom profiles were introduced users could define which events were included in each profile.
“Your most unhappy customers are your greatest source of learning.” -Bill Gates
User of Family Historian 6.2.7, Rootsmagic 7.5.8, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)
Posted 12 October 2017 - 12:22 PM
For me, that would mean editing and unchecking about 80 fact types for a Gedcom export. Then I would have to re-edit and check those boxes again when I want a more inclusive Gedcom. As you say, quite laborious.
I would urge the developers to design a fact type filter that can be accessed from the file export page, not the fact type list page. The same filter could be accessible when creating HTML files, printing family group sheets, printing narrative reports or any other report that requires a selection of fact types in the report. The "Include when:" options could then be eliminated from the fact type list options.
Posted 12 October 2017 - 12:52 PM
Confirming this is on the enhancement request list.
Posted 28 April 2018 - 12:14 PM
I'm glad to see this is on the enhancement request list, but is there any kind of reasonable way to achieve a BMDB only export in the meantime?
as of Nov 2010: converting from TMG to RM
Posted 28 April 2018 - 03:15 PM
This wish list item actually has a much larger context. Fact list management in RM is extremely inflexible, and almost all aspects of Fact List management need major changes to enhance usability and user productivity. I have no idea when/if such needed changes will be implemented. Here are the issues as I see them.
- Sentence templates are tied to the Fact List. Suppose that on Mondays, Wednesdays, and Fridays you wish to use one set of sentence templates and that on Tuesdays, Thursdays, and Saturdays you wish to use a different set of sentence templates. The days of the week are obviously just a metaphor for needing to make bulk changes to the sentence templates on a regular basis. For example, you might have a set of sentence templates that are verbose and a set of sentence templates that are terse. You might have a set of sentence templates that are formal and a set of sentence templates that are informal. You might have a set of sentence templates that are in English and a set of sentence templates that are in French. And suppose you want to switch back and forth on a regular basis. It's essentially impossible. Instead of being tied to the Fact List on a one-to-basis, the sentence templates need to be in their own separate table that is joined to the Fact List. And the Sentence Template table should support multiple sets of sentence templates. You might call them different styles. So we could say that RM needs to support a library of sentence template styles. Without something like this, is seems to me that support for multiple languages in RM is essentially impossible. Well, if not impossible then multiple language support would be just as inflexible as the existing sentence template structure unless there could be multiple sets of sentence templates.
- It needs to be possible and easy to export and import such sentence templates between RM databases. At the present time, it is impossible to move sentence templates from one database to the other for the built-in fact types except as a part of a GEDCOM export/import (or a drag and drop, which is actually the same thing as a GEDCOM export/import) from one RM database to a new and empty RM database.
- Just as sentence templates are tied to the Fact List, so also are GEDCOM export options. GEDCOM export options on a fact by fact basis are just as inflexible as are sentence templates. The options need to be removed from the Fact List and moved to a new table that is joined to the Fact List table. And in the new table, RM needs to support multiple sets or styles of output options. For example, one style of output options could be "export all fact types" and another set style of output options could be "export only BMD events". These styles of output options shouldn't be hardwired into RM. Users should be able to add and edit styles of output options. And GEDCOM really needs an option for "exporting everything" which is independent of the style libraries for such things as dragging and dropping one RM database to another for yourself. Otherwise, data can be lost without you having a clue that it was lost.
- The styles of output options shouldn't be just for GEDCOM output. They should also be for output to ancestry.com through the ancestry API and for output to FamilySearch through the FamilySearch API.
- The styles of output options for facts should also extend to all the other items in the "Include when" list you see when editing a Fact Type: publish online/create HTML (which should be separated into different options), family group sheets, narrative reports, individual summaries, and printed lists.
- The style library for output should support such things as merging Places with Place Details and converting Shared Fact roles into actual facts, obviously on an optional basis, specified separately for each style in the output style library. For example (and if I understand correctly), RM presently merges Places with Place Details on output to ancesty.com but not for GEDCOM output nor for output to FamilySearch, and there are no options to influence any of this behavior.
Posted 28 April 2018 - 08:11 PM
is there any kind of reasonable way to achieve a BMDB only export in the meantime?
If using an outboard tool to change your fact type settings to export only BMDB and to set them back again after your export seems reasonable to you, then, yes.
Posted 28 April 2018 - 08:54 PM
Here is one other thing I forgot in my suggestion for improved Fact List support. If the user were editing, for example, all the export options for the BMD export style sheet, then all the facts and their export options should be displayed in one large spreadsheet style display. Think of the way People View looks and works, except it's for the Fact List. Each row would be a fact type and each column would be one of the export options (e.g., Export in GEDCOM, Combine Place and Place Details in GEDCOM export, etc.). Within any particular style sheet, you could see the options at a glance, you could sort a column by clicking the top of the column so the On and Off options for that column would go to the top or bottom, and you could click a cell to flip an On to Off or an Off to an On. It shouldn't ask you any silly questions about whether you really meant it. It should just do it, whatever "it" is. The same sort of display would be available for sentence templates where there probably would just be two columns, one narrow one with the fact type and one very wide column with the sentence template. For the sentence templates, the editing should be in the cell, not in a drop down box.
This same Fact List style sheet interface would also allow the creation of Fact List style sheets and the deletion, editing, and copying of existing Fact List style Sheets. There should be default style Fact List style sheets that could be copied but that could not be edited or deleted. For example, if a default Fact List style sheet met most of your needs, you could just copy it, make any desired changes in the copy, and then tell your next report or your next GEDCOM export of whatever to use the new Fact List style sheet you just created.
A tricky part of this idea for the developers is that any newly added fact would have to add a row to every Fact List style sheet and any deleted fact would have to delete a row from every Fact List style sheet.