From: Peter L. <pet...@te...> - 2008-01-09 20:39:13
|
Hi, The setup view in "Family Lines Graph" becomes wider than my screen (1024*768). I see about 90%. It's no real problem as I can move it to the left and see the rigthmost 10%. Would it be possible to have two levels/rows of tabs with say 4 + 5 in the rows? /Peter |
From: Duncan L. <dli...@gm...> - 2008-01-10 10:03:31
|
On Wed, 2008-01-09 at 21:40 +0100, Peter Landgren wrote: > Hi, > > The setup view in "Family Lines Graph" becomes wider than my screen > (1024*768). I see about 90%. Mine is huge as well. Perhaps the tabs need to be in two rows? Revision 9774. Duncan |
From: Brian M. <br...@gr...> - 2008-01-10 12:52:55
|
> > The setup view in "Family Lines Graph" becomes > wider than my screen > > (1024*768). I see about 90%. > Mine is huge as well. Perhaps the tabs need to be in > two rows? > Revision 9774. It's also possible that a couple of tabs could be combined or the names shortened. ~Brian |
From: Peter L. <pet...@te...> - 2008-01-10 13:27:02
|
> > > The setup view in "Family Lines Graph" becomes > > > > wider than my screen > > > > > (1024*768). I see about 90%. > > > > Mine is huge as well. Perhaps the tabs need to be in > > two rows? > > Revision 9774. > > It's also possible that a couple of tabs could be > combined or the names shortened. > > ~Brian Yes, sounds good. The problem for me as translator is that many Swedish words are longer than the English. With 9 tabs and say three characters extra in each tab-word gives a 27 characters wider views. /Peter -- Peter Landgren Talken Hagen 671 94 Brunskog SWEDEN 0570-530 21 070-635 4719 pet...@te... skype:pgl4820.2 |
From: Peter L. <pet...@te...> - 2008-01-13 12:32:00
|
Hi, I have run a couple of tests and it looks nice. However, if I include places I get the "City", which may not be the most appropriate type of place. (At least not for Sweden.) I would prefer "Place Name" or "Church parish". Or even better being able to choose at least one type of place from all available possibilities. If a person has immigrated/emigrated it would be nice to have the country too. /Peter |
From: <ste...@gm...> - 2008-01-13 19:02:34
|
That was intentional, and it reflects my own genealogy. In my case 99% of the people going back to the early 1600s come from the same province/country, so in the FamilyLines code when I have an individual city, I opted to just use that instead of filling up the graph with hundreds of copies of the same province name and country name. What would people like to see? The title of the place? Or the city/country combined? It all comes down to space on the graph -- how can I try to shorten the names as much as possible. What I would like to avoid is very large text boxes, for example: Joe Q. Public (1800-01-01 - 1875-12-31) Beauport, Montmorency, Qu=E9bec, Canada - Saint-Alexandre, Saint-Alexandre-de-Kamouraska, Qu=E9bec, Canada ...versus what gets printed now: Joe Q. Public (1800-01-01 - 1875-12-31) Beauport - Saint-Alexandre But again, this shows how it works only when the person looking at the output of FamilyLines is familiar with the geography of their ancestors. If you have ancestors from all over Europe, just having a city name may not help much. Anyone have a good suggestion? St=E9phane On Jan 13, 2008 4:33 AM, Peter Landgren <pet...@te...> wrote: > Hi, > I have run a couple of tests and it looks nice. > > However, if I include places I get the "City", which may not be the most > appropriate type of place. (At least not for Sweden.) I would prefer "Pla= ce > Name" or "Church parish". Or even better being able to choose at least on= e > type of place from all available possibilities. If a person has > immigrated/emigrated it would be nice to have the country too. > > /Peter > |
From: Ken <ma...@sl...> - 2008-01-13 19:30:01
|
What about giving the user a choice, as in the Reports > Graphical Reports > Ancestral Graph / Descendant Graph with an explanation (maybe in a yellow pop up tag, or similar) stating that some formats may make difficult to read. Ken. Stéphane Charette wrote: > That was intentional, and it reflects my own genealogy. In my case > 99% of the people going back to the early 1600s come from the same > province/country, so in the FamilyLines code when I have an individual > city, I opted to just use that instead of filling up the graph with > hundreds of copies of the same province name and country name. > > What would people like to see? The title of the place? Or the > city/country combined? > > It all comes down to space on the graph -- how can I try to shorten > the names as much as possible. What I would like to avoid is very > large text boxes, for example: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport, Montmorency, Québec, Canada - Saint-Alexandre, > Saint-Alexandre-de-Kamouraska, Québec, Canada > > ...versus what gets printed now: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport - Saint-Alexandre > > > But again, this shows how it works only when the person looking at the > output of FamilyLines is familiar with the geography of their > ancestors. If you have ancestors from all over Europe, just having a > city name may not help much. > > Anyone have a good suggestion? > > Stéphane > > > On Jan 13, 2008 4:33 AM, Peter Landgren <pet...@te...> wrote: > >> Hi, >> I have run a couple of tests and it looks nice. >> >> However, if I include places I get the "City", which may not be the most >> appropriate type of place. (At least not for Sweden.) I would prefer "Place >> Name" or "Church parish". Or even better being able to choose at least one >> type of place from all available possibilities. If a person has >> immigrated/emigrated it would be nice to have the country too. >> >> /Peter >> >> > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Peter L. <pet...@te...> - 2008-01-13 19:32:10
|
Yes, I see the problem with space in the graph.=20 In Sweden city is not the best choice. It has incorporated many surrounding= =20 parishes and people, maybe tens of miles away, does not feel that they are= =20 born in the city. =20 So much of this falls back to how to best describe places. I looked in the= =20 code and you start with city, if it exists, and go to larger areas if not.= =20 Why not start with "Place Name"? /Peter Den Sunday 13 January 2008 20.02.37 skrev St=E9phane Charette: > That was intentional, and it reflects my own genealogy. In my case > 99% of the people going back to the early 1600s come from the same > province/country, so in the FamilyLines code when I have an individual > city, I opted to just use that instead of filling up the graph with > hundreds of copies of the same province name and country name. > > What would people like to see? The title of the place? Or the > city/country combined? > > It all comes down to space on the graph -- how can I try to shorten > the names as much as possible. What I would like to avoid is very > large text boxes, for example: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport, Montmorency, Qu=E9bec, Canada - Saint-Alexandre, > Saint-Alexandre-de-Kamouraska, Qu=E9bec, Canada > > ...versus what gets printed now: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport - Saint-Alexandre > > > But again, this shows how it works only when the person looking at the > output of FamilyLines is familiar with the geography of their > ancestors. If you have ancestors from all over Europe, just having a > city name may not help much. > > Anyone have a good suggestion? > > St=E9phane > > On Jan 13, 2008 4:33 AM, Peter Landgren <pet...@te...> wrote: > > Hi, > > I have run a couple of tests and it looks nice. > > > > However, if I include places I get the "City", which may not be the most > > appropriate type of place. (At least not for Sweden.) I would prefer > > "Place Name" or "Church parish". Or even better being able to choose at > > least one type of place from all available possibilities. If a person h= as > > immigrated/emigrated it would be nice to have the country too. > > > > /Peter =2D-=20 Peter Landgren Talken Hagen 671 94 Brunskog SWEDEN 0570-530 21 070-635 4719 pet...@te... skype:pgl4820.2 |
From: James G. S. (jim) <jg...@sa...> - 2008-01-13 19:41:23
|
Stéphane Charette wrote: > That was intentional, and it reflects my own genealogy. In my case > 99% of the people going back to the early 1600s come from the same > province/country, so in the FamilyLines code when I have an individual > city, I opted to just use that instead of filling up the graph with > hundreds of copies of the same province name and country name. > > What would people like to see? The title of the place? Or the > city/country combined? > > It all comes down to space on the graph -- how can I try to shorten > the names as much as possible. What I would like to avoid is very > large text boxes, for example: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport, Montmorency, Québec, Canada - Saint-Alexandre, > Saint-Alexandre-de-Kamouraska, Québec, Canada > > ...versus what gets printed now: > > Joe Q. Public > (1800-01-01 - 1875-12-31) > Beauport - Saint-Alexandre > > ..<older thread-text snipped> 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 PLACE_STRUCTURE: = n PLAC <PLACE_VALUE> {1:1} +1 FORM <PLACE_HIERARCHY> {0:1} +1 <<SOURCE_CITATION>> {0:M} +1 <<NOTE_STRUCTURE>> {0:M} The documentaion further explains """ PLACE_HIERARCHY: = {Size=1:120} This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a GEDCOM transmission, it implies that all place names follow this jurisdictional format and each jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names. """ ..at least it illustrates other/related thoughts.. Regards, ..jim |
From: Duncan L. <dli...@gm...> - 2008-01-22 20:30:31
|
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 |
From: Dave W. <dw-...@di...> - 2008-02-03 22:55:02
|
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 |
From: Gerald B. <ger...@gm...> - 2008-02-04 15:13:10
|
While we're at it, let's address an old itch of mine: ==Reconcile Places and Addresses=== Rationel: 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 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 > |
From: Dave W. <dw-...@di...> - 2008-02-16 23:11:22
|
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). 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 >> |
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 > |
From: Dave W. <dw-...@di...> - 2008-02-18 00:31:36
|
Benny Malengier wrote: > 2008/2/17, Dave Walton <dw-...@di... <mailto:dw-...@di...>>: > > 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 ;-) On the contrary, one might argue that as a genealogy app, Gramps is the ultimate PIM. :) A PIM lives in the now. All it cares about is the current details for people, and has no concept of sources or history. I'm simply observing that things like email addresses and web pages apply to a certain period of time, like addresses. Which leads me to wonder why Gramps has them, but doesn't allow for either source references or historical placement for them. Also, phone numbers and addresses no longer have a 1:1 relationship, or even matching timespans. I've had the same number at multiple addresses, and I know people who have had several different numbers at one address. So my point is that, for different reasons, Gramps is unable to capture the timeline aspects of things like phone numbers and email addresses. And while I expected someone might point out that Gramps isn't a PIM, and agree with that distinction, I think you'll also agree that a PIM is a poor genealogy application. > Apart from that, read: > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F That's an interesting article. Thanks for the tip. It makes a good argument for me to go change my Address records to Residence events (which I previously didn't pay much attention to). One of the things that has bugged me about Address, and I suspect was at least partly Gerald's motivation, is that it uses its own data fields instead of referencing a Place. After reading that article, I realize that if you change Address to reference a Place, you've turned it into a Residence event. So what's really been bugging me is that I've been using Addresses instead of Residence events. :) The article mentions that the disadvantage of using Residence events is that alternate locations for a Place don't have date spans. Note that one of Gerald's suggestions was to add a date span to alternate locations. I suspect that if that were done, most of his points would be satisfied by using Residence events instead of Addresses. But now I'm puzzled... Why does Address exist? Dave |
From: Benny M. <ben...@gm...> - 2008-02-18 08:08:20
|
2008/2/18, Dave Walton <dw-...@di...>: > > Benny Malengier wrote: > > 2008/2/17, Dave Walton <dw-...@di... <mailto: > dw-...@di...>>: > > > > 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 ;-) > > On the contrary, one might argue that as a genealogy app, Gramps is the > ultimate PIM. :) > > A PIM lives in the now. All it cares about is the current details for > people, and has no concept of sources or history. I'm simply observing > that things like email addresses and web pages apply to a certain period > of time, like addresses. Which leads me to wonder why Gramps has them, > but doesn't allow for either source references or historical placement > for them. Also, phone numbers and addresses no longer have a 1:1 > relationship, or even matching timespans. I've had the same number at > multiple addresses, and I know people who have had several different > numbers at one address. > > So my point is that, for different reasons, Gramps is unable to capture > the timeline aspects of things like phone numbers and email addresses. > And while I expected someone might point out that Gramps isn't a PIM, > and agree with that distinction, I think you'll also agree that a PIM is > a poor genealogy application. > > > Apart from that, read: > > > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F > > That's an interesting article. Thanks for the tip. It makes a good > argument for me to go change my Address records to Residence events > (which I previously didn't pay much attention to). > > One of the things that has bugged me about Address, and I suspect was at > least partly Gerald's motivation, is that it uses its own data fields > instead of referencing a Place. After reading that article, I realize > that if you change Address to reference a Place, you've turned it into a > Residence event. So what's really been bugging me is that I've been > using Addresses instead of Residence events. :) > > The article mentions that the disadvantage of using Residence events is > that alternate locations for a Place don't have date spans. Note that > one of Gerald's suggestions was to add a date span to alternate > locations. I suspect that if that were done, most of his points would > be satisfied by using Residence events instead of Addresses. > > But now I'm puzzled... Why does Address exist? It is part of GEDCOM, and the usage according to GEDCOM is for direct mailing (http://genealogy.about.com/library/weekly/aa110100d.htm ). So an address that is no longer valid as in not in use, is no use as you can't use it for mailing anymore, and should be deleted in that context. You must remember that GRAMPS started as a GEDCOM editor. Things like address should be redesigned so as to let users intuitively understand what it is for. Benny |
From: Bernard <bee...@gm...> - 2008-02-18 12:08:57
|
It should be a sort of query (not editable) - composed of fields extracting events with the meaning of "Last principal residence, email, phone,... " On Feb 18, 2008 9:08 AM, Benny Malengier <ben...@gm...> wrote: > > > 2008/2/18, Dave Walton <dw-...@di...>: > > > Benny Malengier wrote: > > > 2008/2/17, Dave Walton <dw-...@di... <mailto: > > dw-...@di...>>: > > > > > > 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 ;-) > > > > On the contrary, one might argue that as a genealogy app, Gramps is the > > ultimate PIM. :) > > > > A PIM lives in the now. All it cares about is the current details for > > people, and has no concept of sources or history. I'm simply observing > > that things like email addresses and web pages apply to a certain period > > of time, like addresses. Which leads me to wonder why Gramps has them, > > but doesn't allow for either source references or historical placement > > for them. Also, phone numbers and addresses no longer have a 1:1 > > relationship, or even matching timespans. I've had the same number at > > multiple addresses, and I know people who have had several different > > numbers at one address. > > > > So my point is that, for different reasons, Gramps is unable to capture > > the timeline aspects of things like phone numbers and email addresses. > > And while I expected someone might point out that Gramps isn't a PIM, > > and agree with that distinction, I think you'll also agree that a PIM is > > a poor genealogy application. > > > > > Apart from that, read: > > > > > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F > > > > That's an interesting article. Thanks for the tip. It makes a good > > argument for me to go change my Address records to Residence events > > (which I previously didn't pay much attention to). > > > > One of the things that has bugged me about Address, and I suspect was at > > least partly Gerald's motivation, is that it uses its own data fields > > instead of referencing a Place. After reading that article, I realize > > that if you change Address to reference a Place, you've turned it into a > > Residence event. So what's really been bugging me is that I've been > > using Addresses instead of Residence events. :) > > > > The article mentions that the disadvantage of using Residence events is > > that alternate locations for a Place don't have date spans. Note that > > one of Gerald's suggestions was to add a date span to alternate > > locations. I suspect that if that were done, most of his points would > > be satisfied by using Residence events instead of Addresses. > > > > But now I'm puzzled... Why does Address exist? > > > It is part of GEDCOM, and the usage according to GEDCOM is for direct > mailing (http://genealogy.about.com/library/weekly/aa110100d.htm ). So an > address that is no longer valid as in not in use, is no use as you can't use > it for mailing anymore, and should be deleted in that context. > You must remember that GRAMPS started as a GEDCOM editor. Things like > address should be redesigned so as to let users intuitively understand what > it is for. > > Benny > > > ------------------------------------------------------------------------- > 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 > > |
From: Rob G. H. <rob...@gm...> - 2008-02-23 00:22:42
|
On Mon, 2008-02-18 at 09:08 +0100, Benny Malengier wrote: > > > 2008/2/18, Dave Walton <dw-...@di...>: > Benny Malengier wrote: > > 2008/2/17, Dave Walton <dw-...@di... > <mailto:dw-...@di...>>: > > > > 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 ;-) > > On the contrary, one might argue that as a genealogy app, > Gramps is the > ultimate PIM. :) > > A PIM lives in the now. All it cares about is the current > details for > people, and has no concept of sources or history. I'm simply > observing > that things like email addresses and web pages apply to a > certain period > of time, like addresses. Which leads me to wonder why Gramps > has them, > but doesn't allow for either source references or historical > placement > for them. Also, phone numbers and addresses no longer have a > 1:1 > relationship, or even matching timespans. I've had the same > number at > multiple addresses, and I know people who have had several > different > numbers at one address. > > So my point is that, for different reasons, Gramps is unable > to capture > the timeline aspects of things like phone numbers and email > addresses. > And while I expected someone might point out that Gramps isn't > a PIM, > and agree with that distinction, I think you'll also agree > that a PIM is > a poor genealogy application. > > > Apart from that, read: > > > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F > > That's an interesting article. Thanks for the tip. It makes > a good > argument for me to go change my Address records to Residence > events > (which I previously didn't pay much attention to). > > One of the things that has bugged me about Address, and I > suspect was at > least partly Gerald's motivation, is that it uses its own data > fields > instead of referencing a Place. After reading that article, I > realize > that if you change Address to reference a Place, you've turned > it into a > Residence event. So what's really been bugging me is that > I've been > using Addresses instead of Residence events. :) > > The article mentions that the disadvantage of using Residence > events is > that alternate locations for a Place don't have date > spans. Note that > one of Gerald's suggestions was to add a date span to > alternate > locations. I suspect that if that were done, most of his > points would > be satisfied by using Residence events instead of Addresses. > > But now I'm puzzled... Why does Address exist? > I agree that address does need some work on it, and some of it might not be necessarily exported to gedcom, but certainly to the database and XML-based exports. I would love to be able to add more than one phone number for someone. Like cell, home, work, etc... I also believe that IM should be added and e-mail address on the address tab also. Personal web pages and ftp sites should be listed under internet only... > It is part of GEDCOM, and the usage according to GEDCOM is for direct > mailing (http://genealogy.about.com/library/weekly/aa110100d.htm ). So > an address that is no longer valid as in not in use, is no use as you > can't use it for mailing anymore, and should be deleted in that > context. > You must remember that GRAMPS started as a GEDCOM editor. Things like > address should be redesigned so as to let users intuitively understand > what it is for. > > Sincerely, Rob > Benny > > ------------------------------------------------------------------------- > 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 |
From: Dave W. <dw-...@di...> - 2008-02-24 20:40:05
|
Benny Malengier wrote: > > 2008/2/18, Dave Walton <dw-...@di... <mailto:dw-...@di...>>: > > Benny Malengier wrote: > > > > Apart from that, read: > > > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F > > That's an interesting article. Thanks for the tip. It makes a good > argument for me to go change my Address records to Residence events > (which I previously didn't pay much attention to). I've done that conversion now, and am quite happy with the results. In the process I even found an error where someone had an Address dated after their death, which wouldn't have happened had I been using Residence events in the first place. I converted all business addresses to Occupation events, and home addresses to Residence events, but that left me with two post office boxes that I'm not sure how to represent as events. Got any ideas? > But now I'm puzzled... Why does Address exist? > > It is part of GEDCOM, and the usage according to GEDCOM is for direct > mailing (http://genealogy.about.com/library/weekly/aa110100d.htm ). So > an address that is no longer valid as in not in use, is no use as you > can't use it for mailing anymore, and should be deleted in that context. > You must remember that GRAMPS started as a GEDCOM editor. Things like > address should be redesigned so as to let users intuitively understand > what it is for. Perhaps a mechanism for marking Residence/Occupation events as being current addresses, which the Addresses tab would then display? But that sounds complicated to implement. In general, I think Places is a better place to spend developer time than Addresses, now that I realize that Addresses aren't what I thought they were. At least, that's where I'd be poking around if I had both free time and Python skills. Alas, I currently have neither, which is quite frustrating, since I keep getting the urge to tweak things. :) Dave |
From: Benny M. <ben...@gm...> - 2008-02-25 08:09:23
|
2008/2/24, Dave Walton <dw-...@di...>: > > Benny Malengier wrote: > > > > 2008/2/18, Dave Walton <dw-...@di... <mailto: > dw-...@di...>>: > > > > > Benny Malengier wrote: > > > > > > Apart from that, read: > > > > > > http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F > > > > That's an interesting article. Thanks for the tip. It makes a good > > argument for me to go change my Address records to Residence events > > (which I previously didn't pay much attention to). > > > I've done that conversion now, and am quite happy with the results. In > the process I even found an error where someone had an Address dated > after their death, which wouldn't have happened had I been using > Residence events in the first place. > > I converted all business addresses to Occupation events, and home > addresses to Residence events, but that left me with two post office > boxes that I'm not sure how to represent as events. Got any ideas? > > > > But now I'm puzzled... Why does Address exist? > > > > It is part of GEDCOM, and the usage according to GEDCOM is for direct > > mailing (http://genealogy.about.com/library/weekly/aa110100d.htm ). So > > an address that is no longer valid as in not in use, is no use as you > > can't use it for mailing anymore, and should be deleted in that context. > > You must remember that GRAMPS started as a GEDCOM editor. Things like > > address should be redesigned so as to let users intuitively understand > > what it is for. > > > Perhaps a mechanism for marking Residence/Occupation events as being > current addresses, which the Addresses tab would then display? But that > sounds complicated to implement. In general, I think Places is a better > place to spend developer time than Addresses, now that I realize that > Addresses aren't what I thought they were. At least, that's where I'd > be poking around if I had both free time and Python skills. Alas, I > currently have neither, which is quite frustrating, since I keep getting > the urge to tweak things. :) Many linux magazines do python code hacking pieces as it is such an easy language to start with. Eg linuxformat (from UK, expensive for USA though that thinks in dollar) is running a series now. Check out the magazine section. It would allow you to read some of the code. Benny |
From: Benny M. <ben...@gm...> - 2008-01-10 10:16:49
|
which version? I think Stephane is rewriting large part for 3.0 and is not finished yet. A pity Xmas is over, you guys can use a widescreen LCD ;-P Benny 2008/1/10, Duncan Lithgow <dli...@gm...>: > > > On Wed, 2008-01-09 at 21:40 +0100, Peter Landgren wrote: > > Hi, > > > > The setup view in "Family Lines Graph" becomes wider than my screen > > (1024*768). I see about 90%. > Mine is huge as well. Perhaps the tabs need to be in two rows? > Revision 9774. > > Duncan > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Ken <ma...@sl...> - 2008-01-10 10:57:33
|
What about all us old people who just do genealogy as a hobby, and are stuck with 15" CRT. ;-) Ken. Benny Malengier wrote: > which version? > > I think Stephane is rewriting large part for 3.0 and is not finished yet. > A pity Xmas is over, you guys can use a widescreen LCD ;-P > > Benny > > 2008/1/10, Duncan Lithgow < dli...@gm... > <mailto:dli...@gm...>>: > > > On Wed, 2008-01-09 at 21:40 +0100, Peter Landgren wrote: > > Hi, > > > > The setup view in "Family Lines Graph" becomes wider than my screen > > (1024*768). I see about 90%. > Mine is huge as well. Perhaps the tabs need to be in two rows? > Revision 9774. > > Duncan > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > <https://lists.sourceforge.net/lists/listinfo/gramps-devel> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Duncan L. <dli...@gm...> - 2008-01-10 11:40:17
|
On Thu, 2008-01-10 at 11:16 +0100, Benny Malengier wrote: > which version? > > I think Stephane is rewriting large part for 3.0 and is not finished > yet. That's right, let's wait and hear when it's ready. Duncan |