Thanks for your post.
On 20/10/12 15:02, Enno Borgsteede wrote:
> Hi Doug,
>> Am I being stupid? - surely the fields in Location already
>> do that when viewed in Place Tree View. Admittedly the names
>> of the fields don't necessarily correspond properly to our
>> particular geography.
> Well, there is a difference between a tree view and tree
> storage. With the latter, gramps and other genealogy
> programs can be way more flexible, and can also present
> locations in a better way to foreign viewers. Let me give
> you an example:
Yes, I take your point.
I admit I often have to "adapt" gramps fieldnames to my
> 1. When I enter a Dutch city in my tree, I just enter the
> name, like Amsterdam. This country is so small that most
> city names are unique, so I can safely leave out the
> province, and I leave out the country too, because it's
> where I live, and where most of the people that see my tree
> live too, so they know what I'm talking about.
> 2. When I upload this tree to Ancestry or any other US site,
> the site can expand Amsterdam to Amsterdam, North Holland,
> The Netherlands, so that it looks right for an international
> audience, including my own family overseas. But when I
> download a normalized GEDCOM from there, and reimport that
> in my tree, I see English names for province and country,
> and I definitely don't want that either, because I'm Dutch.
> 3. Likewise, when I enter a German town, I may enter Spenge,
> Noord-Rijn Westfalen, Duitsland, which again is not very
> understandable for my overseas cousins, because the younger
> ones there don't understand Dutch, and again, I'm not
> willing to use English names in my database, or German ones
> when I send my tree to German genealogists.
> With a true hierarchical location model, you can store
> countries, states, and provinces in such a way that I can
> choose to make Amsterdam refer to the province of Noord
> Holland, and when the model allows for that, I may use the
> shorthand NH for reports, or even North Holland when I want
> to present the name in a more narrative way for US users.
> Using NH might make them think that I'm referring to New
> Hampshire, which is not the case. And in this case, I would
> have to make sure that my province location refers to the
> kingdom of The Netherlands, or Nederland in my own language,
> or NL, whatever you want.
Understood - see above.
>> In relation to grave location, as examples, graves in
>> Newcastle, UK: England=>Northumberland=>Newcastle upon Tyne.
>> The "Church Parish" is recorded as "Jesmond Road Cemetery",
>> the "Street" as "No 5461 Area XXIV Sub Area 7a Grave 5",
>> therefore different from another grave in the same cemetery
>> having the "Street" "No 8284 Area XXIV Sub Area B3 Grave 1".
>> So each grave has its own particular lat and long.
>> Am I missing something?
> Yes. With this approach, you can't easily record the street
> address of the cemetery itself, which I think is important
> for those who actually want to drive there. The coordinates
> of the grave itself are not very useful then, I think,
> especially if the cemetery is large, and the grave is close
> to a street that has no gate to the cemetery itself.
Yes, I see that. In such circumstances I would probably have
"adapted" the Locality field to enter the actual street
name, trying to keep the hierarchical arrangement, but it
definitely ends up getting very contorted.
As far as using coordinates for driving are concerned, I
would normally put the lat/long of the grave into Google
Maps; then look at the map it produced (or use a
marine-capable GPS) and maybe use Street View.
> With a true hierarchical model, you can enter coordinates at
> each level if you want, so you can record both the locatin
> of the gate and of the grave itself.
That's a very nice idea.
And when done right,
> you can look up most places from servers on the web, that
> may even supply names in different languages.
> Here's an example of a new project that can standardize
> places, BTW:
Cheers and many thanks,