From: Benny M. <ben...@gm...> - 2008-02-17 09:51:29
|
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 > |