Q.

If I have a database file, how much work is involved in getting the data to display on a map?

A.

Normally, very little. The import routine allows you to select fields in the external file that hold the geographical information - such as a parish/place name, and an optional county name. So, a database file with a record containing "Winchester" and "Hampshire" (or 'HAM') respectively in two separate fields would be no problem.

Q.

But how does the program know where to plot this imported data?

A.

It has a large database of placenames, together with their map co-ordinates. So it reads through your list of places, and tries to match them against places it knows about.

Q.

Fine, but my database is not in dBase (.DBF) format

A.

Fortunately you can create a DBF file very easily from many popular Windows applications, such as MS Access, Excel, Paradox, MS Works, etc.

Q.

O.K, but what about a GEDCOM file?

A.

The import routine has to extract the place information from a single record in the Gedcom file, i.e. the 'PLAC' tag. This is always going to be more error-prone than using a database. So its success at recognising places depends to a great extent on how you formatted this information in the original genealogy package. Having said that, the recognition engine is fairly tolerant of syntax variations, e.g. it knows about common county abbreviations and Chapman county codes, and can even deal with some variation in the spelling of place names. To take an example, "Winchester, Hampshire", "Winchester, Hants", or "Winchester, HAM" (comma-separated) should all work O.K. It can also deal with extracting a place and county from a longer address string, even if the place/county elements do not occur at the end of the string.

Q.

What does the program do with the places it can't identify?

A.

It creates records for them in the GenMap data table, reproducing the syntax of the original. You can then use facilities within the program to turn them into 'real' placenames and get them plotted on the map.