From: Albert <alb...@ho...> - 2012-10-19 08:42:26
|
Dear all, I feel I belong to the last generation which still knows by memory where our ancestors graves are located. In order to help the followers to occasionally visit our families graves, I started surveying graves with GPS. I am experiencing difficulties to specify in which grave such ancestor was buried. I could not update the location of the burial. It is systematically reverted to the prior location. Should I cancel the burial event and recreate it with the grave location? Did any of you met and solve that problem? Thank you in advance for your suggestions> * Albert ANDRE* |
From: Enno B. <enn...@gm...> - 2012-10-19 13:03:17
|
Hello Albert, I feel I belong to the last generation which still knows by memory where our ancestors graves are located. In order to help the followers to occasionally visit our families graves, I started surveying graves with GPS. I am experiencing difficulties to specify in which grave such ancestor was buried. I could not update the location of the burial. It is systematically reverted to the prior location. Should I cancel the burial event and recreate it with the grave location? Did any of you met and solve that problem? I never used coordinates up till now, but I just tried adding them, and found that Gramps does seem to save them properly. That means, that when I open the same location later, I see the coordinates that I entered. I tried this with the Windows version and the latest 3.4 development version on Xubuntu. There is a scenario that can easily go wrong however, and that one occurs when you have several family members buried in different graves on the same grave yard. Now, when you have one location entry in Gramps for that grave yard, every time you enter coordinates for a grave on that yard, you actually change the coordinates of the grave yard itself. So, when you enter coordinates for two graves on that same yard, in sequence, you will find that when you check the position of the first grave, you see the coordinates that you entered for the second one, which makes you think that it is somehow reverted. And the answer then is, that it was reverted, by yourself! As far as I know, Gramps can only store coordinates in the location table, so you have to make sure that each grave gets its own entry in that table. That means that you are sort of forced to use location names that include a grave number, or grave name, so that you can keep those entries separate. I hope that I guessed right, and that this solves your problem. If it does not, please tell us exactly what you did, so we can reproduce the problem. regards, Enno |
From: Jesse M. <da...@gm...> - 2012-10-19 18:07:40
|
On Fri, Oct 19, 2012 at 8:03 AM, Enno Borgsteede <enn...@gm...> wrote: > ** > As far as I know, Gramps can only store coordinates in the location table, > so you have to make sure that each grave gets its own entry in that table. > That means that you are sort of forced to use location names that include a > grave number, or grave name, so that you can keep those entries separate. > > I hope that I guessed right, and that this solves your problem. If it does > not, please tell us exactly what you did, so we can reproduce the problem. > > While it isn't perfect, I have used the description to store specific addresses. Yes, it does have a drawback when it comes to mapping, but it prevents my locations from spiraling out of control. I do wish that Gramps's location handling was better though. The ability to nest locations, for example, so that Sweden is one location, Stockholm is a subset of Sweden, and a specific address is a subset of Stockholm. |
From: Peter L. <pet...@te...> - 2012-10-19 18:44:34
|
Jesse Meyer skrev 2012-10-19 20:07: > On Fri, Oct 19, 2012 at 8:03 AM, Enno Borgsteede <enn...@gm... > <mailto:enn...@gm...>> wrote: > > As far as I know, Gramps can only store coordinates in the > location table, so you have to make sure that each grave gets its > own entry in that table. That means that you are sort of forced to > use location names that include a grave number, or grave name, so > that you can keep those entries separate. > I hope that I guessed right, and that this solves your problem. If > it does not, please tell us exactly what you did, so we can > reproduce the problem. > > While it isn't perfect, I have used the description to store specific > addresses. Yes, it does have a drawback when it comes to mapping, but > it prevents my locations from spiraling out of control. > I do wish that Gramps's location handling was better though. The > ability to nest locations, for example, so that Sweden is one > location, Stockholm is a subset of Sweden, and a specific address is a > subset of Stockholm. Doug and I have discussed this and made some tests some time ago. One problem is that a working hierarchy in one country does not necessary work for other countries . /Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users |
From: Jesse M. <da...@gm...> - 2012-10-19 19:35:37
|
On Fri, Oct 19, 2012 at 1:44 PM, Peter Landgren <pet...@te...>wrote: > Jesse Meyer skrev 2012-10-19 20:07: > >> I do wish that Gramps's location handling was better though. The ability >> to nest locations, for example, so that Sweden is one location, Stockholm >> is a subset of Sweden, and a specific address is a subset of Stockholm. > > Doug and I have discussed this and made some tests some time ago. One > problem is that a working hierarchy in one country does not necessary > work for other countries . > I'm not seeing why the hierarchy needs to be defined in the code, as long as it is possible to specify that place B is a subset of place A, and that place B shares certain fields with place A. So, for example, Sweden would have a country field of "Sweden". Stockholm would mark that it shares the country field with Sweden, but the other fields would be different. Hmmm, one way of doing that would be that is that a sublocation inherits all information of the parent location unless the information is specifically supplied for the sublocation. Can you see any problems with this setup? Well, other than someone would have to code it. ;) |
From: Peter G <sai...@ya...> - 2012-10-20 05:21:40
|
Uh, this sort of already happens. If you are in Places, with Tree View, expand the country Sweden and make it active. If you then add a location, it will inheirit the property of Sweden. Same if you are in Sweden plus the next unit (state field) and then add a place it will start out with Sweden and the "state" name filled out. Peter >________________________________ > From: Jesse Meyer <da...@gm...> > >I'm not seeing why the hierarchy needs to be defined in the code, as long as it is possible to specify that place B is a subset of place A, and that place B shares certain fields with place A. > >So, for example, Sweden would have a country field of "Sweden". Stockholm would mark that it shares the country field with Sweden, but the other fields would be different. > >Hmmm, one way of doing that would be that is that a sublocation inherits all information of the parent location unless the information is specifically supplied for the sublocation. > >Can you see any problems with this setup? Well, other than someone would have to code it. ;) > > |
From: doug <do...@o2...> - 2012-10-20 11:28:54
|
On 19/10/12 20:35, Jesse Meyer wrote: > On Fri, Oct 19, 2012 at 1:44 PM, Peter Landgren > <pet...@te... <mailto:pet...@te...>> wrote: > > Jesse Meyer skrev 2012-10-19 20:07: > > I do wish that Gramps's location handling was better > though. The ability to nest locations, for > example, so that Sweden is one location, Stockholm > is a subset of Sweden, and a specific address is a > subset of Stockholm. > Doug and I have discussed this and made some tests some > time ago. One problem is that a working hierarchy in one > country does not necessary > work for other countries . > >  > I'm not seeing why the hierarchy needs to be defined in the > code, as long as it is possible to specify that place B is a > subset of place A, and that place B shares certain fields > with place A. >  > So, for example, Sweden would have a country field of > "Sweden". Stockholm would mark that it shares the country > field with Sweden, but the other fields would be different. >  > Hmmm, one way of doing that would be that is that a > sublocation inherits all information of the parent location > unless the information is specifically supplied for the > sublocation. >  > Can you see any problems with this setup? Well, other than > someone would have to code it. ;) Am I being stupid? - surely the fields in Location already do that when viewed in Place Tree View. Admittedly the names of the fields don't necessarily correspond properly to our particular geography. For example Country=>County=>City (UK) or Country=>State=>County=>City (US). In relation to grave location, as examples, graves in Newcastle, UK: England=>Northumberland=>Newcastle upon Tyne. The "Church Parish" is recorded as "Jesmond Road Cemetery", the "Street" as "No 5461 Area XXIV Sub Area 7a Grave 5", therefore different from another grave in the same cemetery having the "Street" "No 8284 Area XXIV Sub Area B3 Grave 1". So each grave has its own particular lat and long. Am I missing something? Doug |
From: Enno B. <enn...@gm...> - 2012-10-20 14:02:56
|
Hi Doug, > Am I being stupid? - surely the fields in Location already > do that when viewed in Place Tree View. Admittedly the names > of the fields don't necessarily correspond properly to our > particular geography. Well, there is a difference between a tree view and tree storage. With the latter, gramps and other genealogy programs can be way more flexible, and can also present locations in a better way to foreign viewers. Let me give you an example: 1. When I enter a Dutch city in my tree, I just enter the name, like Amsterdam. This country is so small that most city names are unique, so I can safely leave out the province, and I leave out the country too, because it's where I live, and where most of the people that see my tree live too, so they know what I'm talking about. 2. When I upload this tree to Ancestry or any other US site, the site can expand Amsterdam to Amsterdam, North Holland, The Netherlands, so that it looks right for an international audience, including my own family overseas. But when I download a normalized GEDCOM from there, and reimport that in my tree, I see English names for province and country, and I definitely don't want that either, because I'm Dutch. 3. Likewise, when I enter a German town, I may enter Spenge, Noord-Rijn Westfalen, Duitsland, which again is not very understandable for my overseas cousins, because the younger ones there don't understand Dutch, and again, I'm not willing to use English names in my database, or German ones when I send my tree to German genealogists. With a true hierarchical location model, you can store countries, states, and provinces in such a way that I can choose to make Amsterdam refer to the province of Noord Holland, and when the model allows for that, I may use the shorthand NH for reports, or even North Holland when I want to present the name in a more narrative way for US users. Using NH might make them think that I'm referring to New Hampshire, which is not the case. And in this case, I would have to make sure that my province location refers to the kingdom of The Netherlands, or Nederland in my own language, or NL, whatever you want. > In relation to grave location, as examples, graves in Newcastle, UK: > England=>Northumberland=>Newcastle upon Tyne. > The "Church Parish" is recorded as "Jesmond Road Cemetery", > the "Street" as "No 5461 Area XXIV Sub Area 7a Grave 5", > therefore different from another grave in the same cemetery > having the "Street" "No 8284 Area XXIV Sub Area B3 Grave 1". > So each grave has its own particular lat and long. > Am I missing something? Yes. With this approach, you can't easily record the street address of the cemetery itself, which I think is important for those who actually want to drive there. The coordinates of the grave itself are not very useful then, I think, especially if the cemetery is large, and the grave is close to a street that has no gate to the cemetery itself. With a true hierarchical model, you can enter coordinates at each level if you want, so you can record both the locatin of the gate and of the grave itself. And when done right, you can look up most places from servers on the web, that may even supply names in different languages. Here's an example of a new project that can standardize places, BTW: https://github.com/DallanQ/Places cheers, Enno |
From: doug <do...@o2...> - 2012-10-20 17:21:18
|
Hi Enno, Thanks for your post. Comments in-line: On 20/10/12 15:02, Enno Borgsteede wrote: > Hi Doug, > >> Am I being stupid? - surely the fields in Location already >> do that when viewed in Place Tree View. Admittedly the names >> of the fields don't necessarily correspond properly to our >> particular geography. > > Well, there is a difference between a tree view and tree > storage. With the latter, gramps and other genealogy > programs can be way more flexible, and can also present > locations in a better way to foreign viewers. Let me give > you an example: Yes, I take your point. I admit I often have to "adapt" gramps fieldnames to my requirements. > > 1. When I enter a Dutch city in my tree, I just enter the > name, like Amsterdam. This country is so small that most > city names are unique, so I can safely leave out the > province, and I leave out the country too, because it's > where I live, and where most of the people that see my tree > live too, so they know what I'm talking about. > 2. When I upload this tree to Ancestry or any other US site, > the site can expand Amsterdam to Amsterdam, North Holland, > The Netherlands, so that it looks right for an international > audience, including my own family overseas. But when I > download a normalized GEDCOM from there, and reimport that > in my tree, I see English names for province and country, > and I definitely don't want that either, because I'm Dutch. > 3. Likewise, when I enter a German town, I may enter Spenge, > Noord-Rijn Westfalen, Duitsland, which again is not very > understandable for my overseas cousins, because the younger > ones there don't understand Dutch, and again, I'm not > willing to use English names in my database, or German ones > when I send my tree to German genealogists. > > With a true hierarchical location model, you can store > countries, states, and provinces in such a way that I can > choose to make Amsterdam refer to the province of Noord > Holland, and when the model allows for that, I may use the > shorthand NH for reports, or even North Holland when I want > to present the name in a more narrative way for US users. > Using NH might make them think that I'm referring to New > Hampshire, which is not the case. And in this case, I would > have to make sure that my province location refers to the > kingdom of The Netherlands, or Nederland in my own language, > or NL, whatever you want. > Understood - see above. >> In relation to grave location, as examples, graves in >> Newcastle, UK: England=>Northumberland=>Newcastle upon Tyne. >> The "Church Parish" is recorded as "Jesmond Road Cemetery", >> the "Street" as "No 5461 Area XXIV Sub Area 7a Grave 5", >> therefore different from another grave in the same cemetery >> having the "Street" "No 8284 Area XXIV Sub Area B3 Grave 1". >> So each grave has its own particular lat and long. > >> Am I missing something? > > Yes. With this approach, you can't easily record the street > address of the cemetery itself, which I think is important > for those who actually want to drive there. The coordinates > of the grave itself are not very useful then, I think, > especially if the cemetery is large, and the grave is close > to a street that has no gate to the cemetery itself. Yes, I see that. In such circumstances I would probably have "adapted" the Locality field to enter the actual street name, trying to keep the hierarchical arrangement, but it definitely ends up getting very contorted. As far as using coordinates for driving are concerned, I would normally put the lat/long of the grave into Google Maps; then look at the map it produced (or use a marine-capable GPS) and maybe use Street View. > > With a true hierarchical model, you can enter coordinates at > each level if you want, so you can record both the locatin > of the gate and of the grave itself. That's a very nice idea. And when done right, > you can look up most places from servers on the web, that > may even supply names in different languages. > > Here's an example of a new project that can standardize > places, BTW: > > https://github.com/DallanQ/Places > > cheers, > > Enno Cheers and many thanks, Doug |
From: Enno B. <enn...@gm...> - 2012-10-20 19:15:04
|
Hi Doug, > I admit I often have to "adapt" gramps fieldnames to my > requirements. You're not the only one. I inherited a large database from my father, who used Brother's Keeper at the time. And he came accross the problem that he found no way to store the religious denomination of his ancestors anywhere in a baptism event. BK had no notes field at the event level, and he thought it was not appropriate to put in the source field either, so he chose to append abbreviations like EL (Evangelical Lutheran), or RK (Roman Catholic) to the baptism date. BK didn't complain about that, but it gave me a lot of warnings when I imported his dataset in PAF, and I decided to remove these abbreviations from these dates, only to find out that PAF didn't have a field for religion either, and neither has Gramps. Now this is an attribute that you could also attach to churches, especially when you add them as a location type, but some churches changed their denomination over time, so it's still some sort of white spot in the data model. And to stay within the subject, I know that a lot of grave yards are also linked to a specific religion, so there is still some information to be gathered from the place where someone was buried. There's a nice page about the subject of places on the Gramps developers wiki: http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling This shows that there are a lot of ways to improve things, on the long term anyway. cheers, Enno |
From: doug <do...@o2...> - 2012-10-21 10:22:16
|
On 20/10/12 20:14, Enno Borgsteede wrote: > Hi Doug, > >> I admit I often have to "adapt" gramps fieldnames to my >> requirements. > > You're not the only one. I inherited a large database from > my father, who used Brother's Keeper at the time. And he > came accross the problem that he found no way to store the > religious denomination of his ancestors anywhere in a > baptism event. BK had no notes field at the event level, and > he thought it was not appropriate to put in the source field > either, so he chose to append abbreviations like EL > (Evangelical Lutheran), or RK (Roman Catholic) to the > baptism date. BK didn't complain about that, but it gave me > a lot of warnings when I imported his dataset in PAF, and I > decided to remove these abbreviations from these dates, only > to find out that PAF didn't have a field for religion > either, and neither has Gramps. > > Now this is an attribute that you could also attach to > churches, especially when you add them as a location type, > but some churches changed their denomination over time, so > it's still some sort of white spot in the data model. And to > stay within the subject, I know that a lot of grave yards > are also linked to a specific religion, so there is still > some information to be gathered from the place where someone > was buried. > > There's a nice page about the subject of places on the > Gramps developers wiki: > > http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling > > > This shows that there are a lot of ways to improve things, > on the long term anyway. Very interesting: it would be nice to see it progressing. A little bit of nit-picking at GEPS_006: the UK proposal leaves out the Church Parish field we have at present; and while it may be redundant for current places, it's often the only information given in early historical records. Cheers, Doug > cheers, > > Enno > > |
From: Enno B. <enn...@gm...> - 2012-10-21 12:03:52
|
Hi Doug, >> There's a nice page about the subject of places on the >> Gramps developers wiki: >> >> http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling >> > > A little bit of nit-picking at GEPS_006: the UK proposal > leaves out the Church Parish field we have at present; and > while it may be redundant for current places, it's often the > only information given in early historical records. Well, the wiki is here for you, so you if you have something to say, please log in and make a change. You may also read and comment on one of the bug tracker entries at the bottom of the page. What you write about the Church Parish is very important, not only for the UK, but also for Germany, Poland, and about every country where the churches had their own geographic hierarchy. And whenever you see an old document from there, it is very likely indeed that the only info that you can read there is a Parish, or a Kirchenkreis in Germany, or whatever it is called somewhere else. The idea that I presented earlier, is nothing new, BTW, as you can see here: http://www.gramps-project.org/bugs/view.php?id=4510 And when you click on the first link that's presented there, http://gov.genealogy.net/search/index, you can see location graphs for lots of places in the world, including the UK. cheers, Enno |