2008/2/17, Dave Walton <firstname.lastname@example.org>:
Gerald Britton wrote:
> While we're at it, let's address an old itch of mine:
> ==Reconcile Places and Addresses===
Yeah, that's been nagging at me for some time, too.
> Both Places (the Location tab) and Addresses hold address data. They
> mostly overlap with a few differences:
> Addresses in gramps have dates, Places do not.
> Places have Church Parish, Addresses do not.
> Places separate City and County, Addresses lump them into one field
> Addresses label one field State/Prov, Places labels the same field State
Also, an Address has a field for a phone number. One phone number.
Plenty of people in my family have two lines at home, so I'd have to add
a second Address to enter their second line. And then there are cell
phones, which aren't tied to an address anyway.
Thinking about it now, addresses, phone numbers, email addresses, web
sites, etc are all ways of locating someone, in one way or another. So
the current Addresses and Internet tabs could be combined into a single
tab (still called Addresses? or Contacts? or ?). That tab could
contain a list of entries of all those types, each with a date range,
source and notes (which Internet tab items currently do not have).
> Have one class to handle both Place Locations and Addresses and one
> object to capture them. Let the attributes be the union of both
> current objects. Manage addresses as objects by themselves.
> In the Place Location dialog, add dates to show when the location (or
> alternate location) is meaningful for the place.
> In both the Address dialog and the Place Location dialog, add the
> ability to lookup an address object.
> Add a button to both dialogs directly access a user-definable GIS
> service like Google Maps, Google Earth, Mapquest, etc.
> Use one dialog for both purposes.
> Code consolidation for easier maintenance and easier feature addition
> (such as hierarchical searching)
> Consistent presentation of civic address data for both Place Locations
> and Addresses
> On Feb 3, 2008 5:55 PM, Dave Walton <email@example.com> wrote:
>> Your suggestion (appended below) of a selectable place structure is an
>> interesting idea, and touches on something I've been pondering. As my
>> list of places grows, it becomes increasingly difficult to find a
>> particular place in the list, just because the list is so long. It
>> would be much tidier if places could be displayed as collapsable
>> hierarchy which one could drill down into to find a specific location.
>> Which then leads to the issue of how that would work with the different
>> structures used in different regions.
>> It occurs to me that the issue could be broken down into two (hopefully
>> separate) parts: data and labels.
>> Looking at the data first, without labels, your NZ example would look
>> like this:
>> level 1: New Zealand
>> level 2: Auckland
>> level 3: Waitakere
>> level 4: New Lynn
>> level 5: 15 William's St
>> Where the levels map to country, region, town, suburb, street.
>> (Or, perhaps country would be level 5, after galaxy, star, planet, and
>> continent. But I digress...)
>> Meanwhile, in England, you might see this:
>> level 1: UK
>> level 2: England
>> level 3: West Midlands
>> level 4: Warwickshire
>> level 5: North Warwickshire
>> level 6: Arley
>> level 7: Old Arley
>> level 8: Church Ln
>> Where the levels map to [?], country, region, county, district, parish,
>> town, street.
>> But within the database, and for purposes of grouping, I don't believe
>> it matters whether country is level 1 or level 2, or whether town is
>> level 3 or level 7. All that matters is that you've got a set of fields
>> which form a hierarchy, and entries which share the same values at the
>> upper levels (regardless of what those values "mean") can be grouped
>> together, down to the level where their values differ.
>> With that in mind, we move on to labels. Your proposal becomes a method
>> of mapping varying sets of labels to the fields for display purposes.
>> In a way, that simplifies things, because the messy details of varying
>> hierarchy styles has become a UI issue, separate from the database.
>> Which is a good thing. The varying place structures is challenging
>> problem, and any simplification is a blessing.
>> What I've been carefully avoiding up to now is non-hierarchical data
>> about a place. A good example of this would be postal code. In one
>> place you might have multiple towns within one postal code, and just a
>> few miles away you might have multiple postal codes within one city. Or
>> a postal code can cover part of one city and all of one or more
>> neighboring towns.
>> This suggests that at the data level you could have some number of
>> hierarchical fields (a dozen?), plus some number of non-hierarchical
>> fields (half a dozen?). Then the place structure labeling system can
>> select labels for the non-hierarchical fields appropriate for that
>> region and time, as well. There would probably also need to be an
>> option to display unlabeled fields, so that if you changed your
>> selection from England to NZ, for example, you wouldn't lose access to
>> the data in levels 6-8.
>> The place where these thoughts become challenging is in sorting the list
>> on a particular value. One possibility would be to sparsely populate
>> the hierarchical fields, so that, for example, 'City' is always level 7,
>> whether or not there are 6 levels above it in a given structure. Or
>> perhaps it would be possible to do something like "sort this list by the
>> contents of the fields which have the label 'City'". More thought is
>> needed here.
>> Anyway, getting back to your suggestion, I like the sound of it.
>> Building the list of structures would be a significant project, but one
>> that non-devs could easily contribute to. And once it was built, it'd
>> be a huge help to the countless users struggling with the question of
>> how to map some random locale to the generic data structure. Though a
>> Generic structure selection would definitely still be necessary.
>> Comments, anyone?
>> Duncan Lithgow wrote:
>>> On Sun, 2008-01-13 at 11:41 -0800, James G. Sack (jim) wrote:
>>>> Perhaps some of this has already been considered by others, and we might
>>>> steal some ideas from there:
>>>> Gedcom has something called a
>>>> PLACE_HIERARCHY within a PLACE_STRUCTURE
>>> Jim, I've been thinking about this for a while now and it seems to me
>>> that the only way to do this properly is to have a setting for each
>>> place which specifies which hiararchical structure to use. For example
>>> If I enter an address from New Zealand it would be:
>>> Structure: New Zealand post 1950
>>> Street: 15 William's St
>>> Suburb: New Lynn
>>> Town/ City: Waitakere
>>> Region: Auckland
>>> Country: New Zealand
>>> (with some fields for Parish and electorate outside the hierarchy)
>>> Whereas if I have an address from Denmark for where my wife's families
>>> tree is it might be:
>>> Structure: Danish 1818-1865
>>> Street (gade): Nansensgade 14
>>> Parish (sogn):
>>> Municipality (kommune):
>>> Region (amt):
>>> Country (land):
>>> (again maybe some fields outside this structure would be useful)
>>> I simply can't see any other way around it.
>>> This approach has some good and bad sides:
>>> * Solves the structure problem which solves a number of other problems
>>> like data consistency, structured reports...
>>> * Includes useful information for the genealogist about how the
>>> geographical names work
>>> * Would require the collection of lots of data to make the system work
>>> * Might be confusing to start with (could also start with Structure:
>>> Maybe we should start by adding to those two lists...
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> Gramps-devel mailing list
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> Gramps-devel mailing list
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Gramps-devel mailing list