Re: [Gramps-devel] Locations / Places and hierarchical structure

[Benny M. <ben...@gm...>]

2008/2/17, Dave Walton <dw-...@di...>:
>
> 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).


Gramps is a genealogy application, not a PIM suite, so I suggest you use one
of the many good addressbooks out there ;-)
Apart from that, read:
http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F

It would be nice to improve on address in GRAMPS, but we would need a
motivated developer for that first. Then a good design, then developer
agreement.

Benny


Dave
>
>
> >
> > Suggestion:
> >
> > 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.
> >
> > Benefits:
> >
> > 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 <dw-...@di...> 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?
> >>
> >> Dave
> >>
> >>
> >>
> >>
> >> 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:
> >>>
> >>> Good:
> >>> * 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
> >>>
> >>> Bad:
> >>> * Would require the collection of lots of data to make the system work
> >>> well
> >>> * Might be confusing to start with (could also start with Structure:
> >>> Generic)
> >>>
> >>> Maybe we should start by adding to those two lists...
> >>>
> >>> Duncan
> >>>
> >>>
> >>>
> -------------------------------------------------------------------------
> >>> This SF.net email is sponsored by: Microsoft
> >>> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>> _______________________________________________
> >>> Gramps-devel mailing list
> >>> Gra...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gra...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>