Difference between revisions of "Geonames"

From Gramps
Jump to: navigation, search
(GEONAMES)
Line 19: Line 19:
 
So, I would prefer to think of all those geographic descriptors as "levels", starting with the country (we can all agree on that, I think) as the base level - Level 0 - and then moving on to Level 1 etc. Having defined our Level 0, all Level 1s are therefore sub-ordinate to it. You can, of course, have as many 'Level 0's as you need.
 
So, I would prefer to think of all those geographic descriptors as "levels", starting with the country (we can all agree on that, I think) as the base level - Level 0 - and then moving on to Level 1 etc. Having defined our Level 0, all Level 1s are therefore sub-ordinate to it. You can, of course, have as many 'Level 0's as you need.
  
So the computer application will think in reverse to us, preferring to start with a country, then finding the names of the places sub-ordinate to it, and so on. Accordingly, the database setup needs to reflect this:
+
So the computer application will think in reverse to us, preferring to start with a country, then finding the names of the places sub-ordinate to it, and so on. Accordingly, the database setup needs to reflect this. As an example:
  
 
{| class="wikitable" style="margin: 1em auto 1em auto" table border="1"
 
{| class="wikitable" style="margin: 1em auto 1em auto" table border="1"
Line 38: Line 38:
  
 
Other places in Los Angeles would "share" the first 3 rows in the table, but then start a new branch.
 
Other places in Los Angeles would "share" the first 3 rows in the table, but then start a new branch.
 +
 +
===GEDCOM===
 +
 +
A well-designed database could derive from a GEDCOM using the correct structure:
 +
 +
0 INDI @987@
 +
1 BIRT
 +
2 DATE 23 JUN 1967
 +
2 PLAC Beverley Hills, Califirnia, USA
 +
3 MAP
 +
4 LATI N34.05
 +
4 LONG 118.230
 +
 +
but in practical use, the last 3 lines can be left out, and the 2 PLAC information linked to a lookup "places" table to prevent bloating the GEEDCOM with repeat information.
  
 
===Discipline===
 
===Discipline===

Revision as of 00:58, 7 November 2007

GEONAMES

This is intended to be a place to discuss place names in Gramps.

Work already done

There is an existing ISO (ISO-3166) that is used as the baseline for geonames. This provides general guidance for abbreviations (eg 2 or 3 character codes, the US 'fips' definitions) for countries.

There are still some confusions in the list - eg, the United Kingdom/Great Britain tangle.

You can see the list at http://www.geonames.org/countries/

Storage methods

When we think about places, we tend to think of them in our own situation. So, I might live at 135 Copley Place, Beverley Hills, Los Angeles, California, USA. (I don't). I think of them, in order, as Address, Suburb, City, State and Country. Other places use different nomenclature - county, province, prefecture, arondisment...to name just a few.

In the world of databases, parsing an address like the one above would be most inefficient - if it could be done at all. It is better to use the database and its strengths to assist us.

So, I would prefer to think of all those geographic descriptors as "levels", starting with the country (we can all agree on that, I think) as the base level - Level 0 - and then moving on to Level 1 etc. Having defined our Level 0, all Level 1s are therefore sub-ordinate to it. You can, of course, have as many 'Level 0's as you need.

So the computer application will think in reverse to us, preferring to start with a country, then finding the names of the places sub-ordinate to it, and so on. Accordingly, the database setup needs to reflect this. As an example:

place# parent# level place long lati
1 0 0 USA W100.00 N39.00
6 1 1 California W119.300 N36.000
7 6 2 Los Angeles W118.230 N34.05
8 7 3 Beverley Hills W118.400 N34.07
25 8 4 135 Copley Place W118.4224 N34.0767

Other places in Los Angeles would "share" the first 3 rows in the table, but then start a new branch.

GEDCOM

A well-designed database could derive from a GEDCOM using the correct structure:

0 INDI @987@ 1 BIRT 2 DATE 23 JUN 1967 2 PLAC Beverley Hills, Califirnia, USA 3 MAP 4 LATI N34.05 4 LONG 118.230

but in practical use, the last 3 lines can be left out, and the 2 PLAC information linked to a lookup "places" table to prevent bloating the GEEDCOM with repeat information.

Discipline

If there is a problem with this, it is that you might need to edit all the geonames in your family file. The strength of the process depends on strict adherence (and identical spelling) to the table structure.

Old place names

If you are going to add Google maps with references from, say, geonames.org, then the old names for places won't be found. The easiest solution to this is to add the old names as notes, but map them with their current names.

Google Group

There is an interesting forum at http://groups.google.com.au/group/geonames?lnk=sg