FamilySearch.org in Africa

I am one of those FamilySearch.org people that you can call if you need help. It is a calling through my ward. I guess they call us Specialists. I can't remember. Anyway, I received an email that referenced http://ghanamtc.blogspot.com/. I was amazed at how many graduating classes of missionaries they have. I have been working with Africa for sometime now. The internet is nothing like we have here. It is very slow and spotty. I am a good PHP programmer and web developer. I was thinking that it might be a good idea to create a dumbed down version of FamilySearch.org. One that does not rely on AJAX. Most web browsers have a JavaScript implementation. A JavaScript/PHP version of FamilySearch.org seems like it would be a better fit for Africa and perhaps, someday, India. It wouldn't have to do everything. When I was being trained as a specialist, they said that the African Saints would have to send everything on paper to Salt Lake to be input. If we could at least develop an input component, I would be a great start.

Okay. I have attached the database I am going to use. It is an SQLite database. I have used my own genealogy. Now for the interface.

I re-thought my think. I was working on databases at work (a redundant comment, I should say working on databases at my place of employment, or something else) and the thought occurred to me that I had multiple indexes going on. I had stolen the structure from someone else, being that I am not familiar with the GEDCOM standard. (I should point out that the Church has started work on GEDCOM X, so it is/was kind of pointless to familiarize myself too much with the old standard.) I had not realized that the original author was keeping dual indexes for the express purpose of being able to convert the data back into the GEDCOM format. It seems that API interaction with FamilySearch would be preferable to converting the data to the GEDCOM format. I dropped the extra indexes.

I have created the index, a page for creating a new individual and a page for modifying an existing individual.

I have worked with Church Neonatal Resuscitation Projects in Africa, and many other Church projects in Africa. Internet is spotty at best. I have been told that each of our meeting houses have generators because of the inconsistent supply of electricity.

In the April 2016 issue of the Liahona it talks about the amazing growth in Africa. Is there anything that a person such as I can do to help bring to fruition verse 39 of Joseph Smith-History?

39 He also quoted the next verse differently: And he shall plant in the hearts of the children the promises made to the fathers, and the hearts of the children shall turn to their fathers. If it were not so, the whole earth would be utterly wasted at his coming.

Microsoft used to have a mdb geneology database that they would let you download. It is gone now, but I was able to find an old copy and re-create the basic database in accdb format. I can make it look a lot cleaner if I use PHP. I usually create SQLite database, but am perfectly comfortable with MySQL. This all makes me wonder. FamilySearch.org will never fly in middle Africa; it requires too many resources (on your computer) and too much bandwidth. An ideal situation would be one where there is enough data on resident on the computer in an African Family History Center to work on ones genealogy without the internet. You would want data transfers to take place as bandwidth is available, but not be dependent on a good connection. A lot of what makes FamilySearch.org exciting is the "bling". Of course, bling isn't required. Neither is a big server. Portability seems to be the answer. Portability like having a small intranet in the history center and having a download/upload manager on the workgroup master computer.

This brings me to the actual application. Openoffice/Libreoffice Base is very temperamental. I have found that PHP is as solid as your coding. Access is not all that Standards Compliant, but it is solid. MySQL is solid as well as is SQLite. I don't know about the latest versions of Access, but I got interested in SQLite because of its ability to maintain multiple connections at the same time. I am sure MySQL is the same. A web interface for the client computers in the group, as well as the master computer seems the most prudent.

Have you reviewed the applications available in the FamilySearch App Gallery? URL: https://familysearch.org/apps/
There are pc and mac applications that allow the user to create and maintain a genealogy database completely off-line and sync to the FamilySearch Family Tree as needed.
There are apps that can be used on a smartphone.
If you're writing apps for use with FamilySearch Family Tree, I hope you're familiar with FamilySearch developer support. See this URL: https://familysearch.org/developer/

I use RootsMagic for my genealogy. I find it interfaces incredibly well. I was thinking though, that it would be nice if we could take all of the records that say, the Hutu tribe has, organize local extraction by the descendants of those who wrote the records, and have a database (comparable to FamilySearch) that the local Hutu peoples can search through and add to.

I see what you are saying rontilby. I really like the "gedcomx-php-sample-app". I believe I will sign up for that one.

richardsontb wrote:I was thinking though, that it would be nice if we could take all of the records that say, the Hutu tribe has, organize local extraction by the descendants of those who wrote the records, and have a database (comparable to FamilySearch) that the local Hutu peoples can search through and add to.

That sounds like a great project that would really be meaningful. Hope you're able to make it happen!

At the beginning of this topic I was working on a php/SQLite/web server solution. It failed because I didn't have the time to hammer it out. In the interim, FamilySearch.org has changed. My favorite change is the completely rebuilt source attachment process. Instead of a source being attached just to the person you are working on, it gets attached to everyone that is referenced. This single change has really improved accuracy (my opinion, not based on actual statistics.) My personal genealogical efforts have been focused on standardizing locations as well as attaching sources that FamilySearch.org finds. I have found that that RootsMagic allows me to pinpoint locations where standardization is needed.

What is my point? A multiplicity of tools in my family history toolbox improves the quality of my work and the amount I can contribute to my ancestors. In working on "FamilySearch.org in Africa", I can see where gedcomx/php can be used to merge data into FamilySearch.org. Using Microsoft Access has allows me a smaller development cycle. Additionally, databases are databases. What I mean is, Microsoft Access allows me to work through some of the structural issues. Later, I can transfer it to MySQL, or whatever. FamilySearch.org shows me one way to solve problems. RootsMagic has shown me others. The open source project GRAMPS has shown me yet more. The key is to make Family History tools accessible to our resource poor Brothers and Sisters.

New version of project.

HCF Project v01.01

Change log:

Added a menu
Fixed "Assign a child to a family"
Changed field name in "Individuals" table

I pulled this project out of my proverbial drawer. It would be wonderful to get some input.

I could really use help with making a tree.

I have the following tables. I use PHP as the interface. I would like to get rid of the Full Name field. I feel that is redundant. I am soliciting input as to how make the Given Name and Surname searchable by Surname first.

Second. How can I learn how to link a database with these tables to FamilySearch? Probably view only.

CREATE TABLE "Families" (
"ID" INTEGER NOT NULL UNIQUE,
"Father ID" integer,
"Mother ID" integer,
"Marriage Date" varchar(50),
"Marriage Location" varchar(255),
PRIMARY KEY("ID" AUTOINCREMENT)
)
CREATE TABLE "FamilySearch" (
"ID" INTEGER NOT NULL UNIQUE,
"Individual ID" INTEGER,
"FamilySearch ID" TEXT,
PRIMARY KEY("ID" AUTOINCREMENT)
)
CREATE TABLE "Individuals" (
"ID" INTEGER NOT NULL UNIQUE,
"Full Name" TEXT,
"Given Name" TEXT,
"Surname" TEXT,
"Sex" TEXT,
"Birth" TEXT,
"Birth Location" TEXT,
"Christening" TEXT,
"Christening Location" TEXT,
"Death" TEXT,
"Death Location" TEXT,
"Burial" TEXT,
"Burial Location" TEXT,
"Family ID" TEXT,
PRIMARY KEY("ID" AUTOINCREMENT)
)
CREATE TABLE "Sex" (
"ID" INTEGER NOT NULL UNIQUE,
"Sex ID" INTEGER,
"Sex" TEXT,
PRIMARY KEY("ID" AUTOINCREMENT)
)