With all the attention I've been paying to places lately I'm wondering if there's any way to get some statistics for them. Stuff like total places, place with the most families/indis, top country, etc. I noticed that the statistics chart has some stuff for distribution but it's not quite what I'm looking for. I checked the keywords for the advanced html block and only found first and latest place keywords for a few things.
I didn't want to put in a feature request just yet in case I'm missing something that's already there. I don't know how hard it would be to add the functionality if it isn't in there either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-17
Yes, this sort of thing has often been raised, but no-one has done it yet. With the many changes Greg has been and is making to the database structure I suspect its probably getting easier to contemplate almost daily. The hardest thing will be deciding what statistics to include - and where to put them. I suspect further extensions to the advanced block (and class_stats.php) would be the easiest way to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<With the many changes Greg has been and is making to the database structure I suspect its probably getting easier to contemplate almost daily.>>
That's kind of my take on the subject also, but I haven't really looked at the db structure for places yet.
<<The hardest thing will be deciding what statistics to include - and where to put them.>>
I was mainly thinking of something similar to surnames I guess. I found myself wondering how many different places I have now and there isn't a simple way to figure it out without drilling down through the hierarchy and counting all the bottom level places. And it seems like top 10 places and maybe the top country could be interesting.
<<I suspect further extensions to the advanced block (and class_stats.php) would be the easiest way to go.>>
That was pretty much where I was thinking. Some interesting stats to catch the eye of visitors in the advanced html block. I've just lately done a little experimenting and I'm quite impressed with the versatility of that block.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every time I look at the phpgedview's representation of places, I remember why I didn't do anything the previous time I looked ;-)
We have a separate place hierarchy for each gedcom - and another one for googlemaps module.
Should we combine this into a single one?
Co-ordinates can come from googlemaps (data entry or csv file import).
The can also come from LATI/LONG records in the gedcom.
Should we try to combine these into a single list?
Should we try to enforce consistent co-ordinates - i.e if we have co-ordinates for "Bethnal Green, London, England", then we'll have the same co-ordinates throughout.
How do we deal with conflicts. i.e when different co-ordinates are attached to the same place.
Should we update the PLAC records in the gedcom to include the LAT/LONG co-ordinates, so that they all stay together when the data is transfered to other applications.
We could store the places internally (and even externally) in the gedcom itself, using custom gedcom tags. e.g.
1 BIRT
2 PLAC Bethnal Green, London, England
2 _PLAC @P1@
....
0 @P1@ _PLAC
1 NAME Bethnal Green, London, England
2 _AKA Bethnal Green, Middlesex, England
2 _AKA Bethnal Green, Londres, Angleterre
1 MAP
2 LATI 0.123E
2 LONG 46.123N
etc.
(Yes - I know there is a defined schema for this - if I had it to hand, I'd quote it!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"We have a separate place hierarchy for each gedcom - and another one for googlemaps module.
Should we combine this into a single one? "
From my point of view, no.
A visitor might be persuaded to return or not return by the knowledge that this particular GEDCOM has lots of people from his ancestral home. Combining other GEDCOMs would weaken that heuristic. More so, if the combination also occurred on his GEDCOM.
Especially if the maps list were thrown in, as that may well contain many places unrelated to the GEDCOM contents.
I have no answer to the other issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow. That's a lot more complex than anything I was thinking of. A fairly simple "74 Individuals were born in Bethnal Green. The Country With Most Events is England, There are 238 Different Birth Places" would make me happy :)
I can see how having the same hierarchy for gedcoms and GM could streamline things a bit. And using LATI/LONG records would save some bother with having to import/export coords for GM.
It gets more complex after that I guess. If you are actually going to use LATI/LONG for anything like the GM module then I imagine it would need to be kept consistent on a per gedcom basis at least.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-17
Ah, now we're getting into a whole new topic - albeit a very important one.
Stew:
There is a chart in the stats page that does show a map of the world (or other areas) highlighted in different shades to indicate the most 'popular' countries. Unfortunately, on my site at least, statistics.php can't run. It times out every time I try.
Re the advanced block - have a look at my welcome page (www.our-families.info, then select "Family Tree"). I ONLY use the advanced block on that page.
Greg - are you actually proposing to introduce a 0 Level tag for places? I sooooo hope so. Been waiting for that to happen for years! On your questions, my opinions would be:
<<Should we combine this into a single one?>> - yes. There are just too many benefits to be gained
<<Should we try to combine these into a single list?>> >> Yes again. GM places and coordinates NEED simplifying.
<<Should we try to enforce consistent co-ordinates >> absolutely. How CAN the same place have different coordinates!
<<How do we deal with conflicts.>> Only a problem initially - so does it matter how? I would just take the first I find. Sure, some tidy up will be needed, but only once.
<<Should we update the PLAC records in the gedcom to include the LAT/LONG co-ordinates, so that they all stay together when the data is transfered to other applications.>> Yes.
Most of this has been discussed before. However, there has never been a process (and probably never will) to actually AGREE on the right answers. Thats one of the biggest reasons (IMHO) this sort of thing never gets done. It just needs someone with the b$%ls to actually DO IT!
One important thing missing from your TAG structure (maybe others too, and I realise you were just jotting thoughts) is the inclusion of media tags. There have been many requests for the ability to add media to places.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<There is a chart in the stats page that does show a map of the world (or other areas) highlighted in different shades to indicate the most 'popular' countries.>>
Yep I saw that. Not all that useful in it's present form because it doesn't show except in a plot. Plus the map is kind of small so it's actually hard to tell which country is which. Certainly a start though :)
<<Re the advanced block - have a look at my welcome page (www.our-families.info, then select "Family Tree"). I ONLY use the advanced block on that page. >>
Interesting. A very good example of the versatility you can get with some effort.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-17
Wes, I think (hope?) Greg was actually referring to the the two separate place TABLES in the DB. 'pgv_places' stores the heirarchy of places for each GEDCOM, and 'pgv_placelocations' stores all the GM Module place coordinates etc. This would /should have no effect on PGVs display of the place list / heirarchy on screen for users. Its just a much more efficient, easier to manage, table structure if they are combined into a single table. He certainly wasn't advocating combining GEDCOMs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What if the googlemaps module accepted and displayed data from klm files instead of the custom csv file used at the moment? This shouldn't be too hard (at least on the GM side) and it would open up a wider array of sources, reduce data preparation time and allow notes, images and historical information to be attached to place data without impacting on the standard GEDCOM file format. Particular gedcom files could then access that data (or a subset) to the extent that the gedcom owner wanted. Some batch set-up and editing tools would be necessary. It might also encourage the building of a central database of place information and a place forum for PGV users. It might also attract others users to PGV.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<What if the googlemaps module accepted and displayed data from klm files instead of the custom csv file used at the moment?>>
IIRC, .klm files are just XML, and converting from CSV to XML is pretty straightforward.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-12-17
Graham's idea has plenty of merit. But what about storage issues? The current csv files do not require uploading to the web, so don't take up unnecessary space. You just import the data from ones you want, when you want them. The data is then stored in a DB table.
My (poor) understanding of .klm files is that these would be permanent fixture on the server, and would replace the GM table completely - or is that not their purpose? I am also assuming, perhaps unfairly, that storing .klm files would be more costly (in space and dollars) than data in a table.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KLM files are xml files with plenty of scope for extra data and plenty of existing data sources and tools available. Place data has simple relationships with family data. Dealing with the place data in klm files would seem to me to be very feasible rather than tinkering with gedcom or waiting eternally for the xml version of gedcom to be accepted and supported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One aspect that I think we need to take in to consideration is the Hierarchy aspect which has map co- ordinates at each node which we have on the current GM module.
The Schema above does not take into account that we need these map co-ordinates at each node. I would envisage the following
0 @P1@ _PLAC
1 NAME Bethnal Green
1 MAP
2 LATI 0.123E
2 LONG 46.123N
1 _PLAC@P2@ Where this points to the next level up in the location hierarchy
0 @P2@ _PLAC
1 NAME London
1 MAP
2 LATI 0.0E
2 LONG 46.0N
1 _PLAC @P3@
0 @P3@ _PLAC
1 NAME England
1 MAP
2 LATI
2 LONG
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pardon me asking, but is do commentators here really mean .kml and .kmz files?
I've used the GoogleMap module since its early days, and find it a useful addition. I've never used the previously included 'map' section of PGV, so, for me, it is not required. And, as I need to trim any instance of PGV to 1000 files or less, all the place/flag data gets short shrift.
I also choose my own 'places' - it is quite quick and easy to get co-ords these days, and it gives me some control over what is being shown. So connections to inbuilt tables - even external sites - are not required.
FWIW :-) and a bit off-topic.....
Paul
Australia
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With all the attention I've been paying to places lately I'm wondering if there's any way to get some statistics for them. Stuff like total places, place with the most families/indis, top country, etc. I noticed that the statistics chart has some stuff for distribution but it's not quite what I'm looking for. I checked the keywords for the advanced html block and only found first and latest place keywords for a few things.
I didn't want to put in a feature request just yet in case I'm missing something that's already there. I don't know how hard it would be to add the functionality if it isn't in there either.
Yes, this sort of thing has often been raised, but no-one has done it yet. With the many changes Greg has been and is making to the database structure I suspect its probably getting easier to contemplate almost daily. The hardest thing will be deciding what statistics to include - and where to put them. I suspect further extensions to the advanced block (and class_stats.php) would be the easiest way to go.
<<With the many changes Greg has been and is making to the database structure I suspect its probably getting easier to contemplate almost daily.>>
That's kind of my take on the subject also, but I haven't really looked at the db structure for places yet.
<<The hardest thing will be deciding what statistics to include - and where to put them.>>
I was mainly thinking of something similar to surnames I guess. I found myself wondering how many different places I have now and there isn't a simple way to figure it out without drilling down through the hierarchy and counting all the bottom level places. And it seems like top 10 places and maybe the top country could be interesting.
<<I suspect further extensions to the advanced block (and class_stats.php) would be the easiest way to go.>>
That was pretty much where I was thinking. Some interesting stats to catch the eye of visitors in the advanced html block. I've just lately done a little experimenting and I'm quite impressed with the versatility of that block.
Every time I look at the phpgedview's representation of places, I remember why I didn't do anything the previous time I looked ;-)
We have a separate place hierarchy for each gedcom - and another one for googlemaps module.
Should we combine this into a single one?
Co-ordinates can come from googlemaps (data entry or csv file import).
The can also come from LATI/LONG records in the gedcom.
Should we try to combine these into a single list?
Should we try to enforce consistent co-ordinates - i.e if we have co-ordinates for "Bethnal Green, London, England", then we'll have the same co-ordinates throughout.
How do we deal with conflicts. i.e when different co-ordinates are attached to the same place.
Should we update the PLAC records in the gedcom to include the LAT/LONG co-ordinates, so that they all stay together when the data is transfered to other applications.
We could store the places internally (and even externally) in the gedcom itself, using custom gedcom tags. e.g.
1 BIRT
2 PLAC Bethnal Green, London, England
2 _PLAC @P1@
....
0 @P1@ _PLAC
1 NAME Bethnal Green, London, England
2 _AKA Bethnal Green, Middlesex, England
2 _AKA Bethnal Green, Londres, Angleterre
1 MAP
2 LATI 0.123E
2 LONG 46.123N
etc.
(Yes - I know there is a defined schema for this - if I had it to hand, I'd quote it!)
"We have a separate place hierarchy for each gedcom - and another one for googlemaps module.
Should we combine this into a single one? "
From my point of view, no.
A visitor might be persuaded to return or not return by the knowledge that this particular GEDCOM has lots of people from his ancestral home. Combining other GEDCOMs would weaken that heuristic. More so, if the combination also occurred on his GEDCOM.
Especially if the maps list were thrown in, as that may well contain many places unrelated to the GEDCOM contents.
I have no answer to the other issues.
Um here's the schema I was thinking of:
http://wiki-en.genealogy.net/wiki/Gedcom_5.5EL
Wow. That's a lot more complex than anything I was thinking of. A fairly simple "74 Individuals were born in Bethnal Green. The Country With Most Events is England, There are 238 Different Birth Places" would make me happy :)
I can see how having the same hierarchy for gedcoms and GM could streamline things a bit. And using LATI/LONG records would save some bother with having to import/export coords for GM.
It gets more complex after that I guess. If you are actually going to use LATI/LONG for anything like the GM module then I imagine it would need to be kept consistent on a per gedcom basis at least.
Ah, now we're getting into a whole new topic - albeit a very important one.
Stew:
There is a chart in the stats page that does show a map of the world (or other areas) highlighted in different shades to indicate the most 'popular' countries. Unfortunately, on my site at least, statistics.php can't run. It times out every time I try.
Re the advanced block - have a look at my welcome page (www.our-families.info, then select "Family Tree"). I ONLY use the advanced block on that page.
Greg - are you actually proposing to introduce a 0 Level tag for places? I sooooo hope so. Been waiting for that to happen for years! On your questions, my opinions would be:
<<Should we combine this into a single one?>> - yes. There are just too many benefits to be gained
<<Should we try to combine these into a single list?>> >> Yes again. GM places and coordinates NEED simplifying.
<<Should we try to enforce consistent co-ordinates >> absolutely. How CAN the same place have different coordinates!
<<How do we deal with conflicts.>> Only a problem initially - so does it matter how? I would just take the first I find. Sure, some tidy up will be needed, but only once.
<<Should we update the PLAC records in the gedcom to include the LAT/LONG co-ordinates, so that they all stay together when the data is transfered to other applications.>> Yes.
Most of this has been discussed before. However, there has never been a process (and probably never will) to actually AGREE on the right answers. Thats one of the biggest reasons (IMHO) this sort of thing never gets done. It just needs someone with the b$%ls to actually DO IT!
One important thing missing from your TAG structure (maybe others too, and I realise you were just jotting thoughts) is the inclusion of media tags. There have been many requests for the ability to add media to places.
<<There is a chart in the stats page that does show a map of the world (or other areas) highlighted in different shades to indicate the most 'popular' countries.>>
Yep I saw that. Not all that useful in it's present form because it doesn't show except in a plot. Plus the map is kind of small so it's actually hard to tell which country is which. Certainly a start though :)
<<Re the advanced block - have a look at my welcome page (www.our-families.info, then select "Family Tree"). I ONLY use the advanced block on that page. >>
Interesting. A very good example of the versatility you can get with some effort.
Wes, I think (hope?) Greg was actually referring to the the two separate place TABLES in the DB. 'pgv_places' stores the heirarchy of places for each GEDCOM, and 'pgv_placelocations' stores all the GM Module place coordinates etc. This would /should have no effect on PGVs display of the place list / heirarchy on screen for users. Its just a much more efficient, easier to manage, table structure if they are combined into a single table. He certainly wasn't advocating combining GEDCOMs.
What if the googlemaps module accepted and displayed data from klm files instead of the custom csv file used at the moment? This shouldn't be too hard (at least on the GM side) and it would open up a wider array of sources, reduce data preparation time and allow notes, images and historical information to be attached to place data without impacting on the standard GEDCOM file format. Particular gedcom files could then access that data (or a subset) to the extent that the gedcom owner wanted. Some batch set-up and editing tools would be necessary. It might also encourage the building of a central database of place information and a place forum for PGV users. It might also attract others users to PGV.
<<What if the googlemaps module accepted and displayed data from klm files instead of the custom csv file used at the moment?>>
IIRC, .klm files are just XML, and converting from CSV to XML is pretty straightforward.
Graham's idea has plenty of merit. But what about storage issues? The current csv files do not require uploading to the web, so don't take up unnecessary space. You just import the data from ones you want, when you want them. The data is then stored in a DB table.
My (poor) understanding of .klm files is that these would be permanent fixture on the server, and would replace the GM table completely - or is that not their purpose? I am also assuming, perhaps unfairly, that storing .klm files would be more costly (in space and dollars) than data in a table.
KLM files are xml files with plenty of scope for extra data and plenty of existing data sources and tools available. Place data has simple relationships with family data. Dealing with the place data in klm files would seem to me to be very feasible rather than tinkering with gedcom or waiting eternally for the xml version of gedcom to be accepted and supported.
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
To pick up Kiwi's point the klm files are just a way of exchanging data just like gedcom and csv. The data would be stored and edited on the database with import/export tools for klm or klz (the zipped up version).
I agree with every thing that Kiwi says.
One aspect that I think we need to take in to consideration is the Hierarchy aspect which has map co- ordinates at each node which we have on the current GM module.
The Schema above does not take into account that we need these map co-ordinates at each node. I would envisage the following
0 @P1@ _PLAC
1 NAME Bethnal Green
1 MAP
2 LATI 0.123E
2 LONG 46.123N
1 _PLAC@P2@ Where this points to the next level up in the location hierarchy
0 @P2@ _PLAC
1 NAME London
1 MAP
2 LATI 0.0E
2 LONG 46.0N
1 _PLAC @P3@
0 @P3@ _PLAC
1 NAME England
1 MAP
2 LATI
2 LONG
Pardon me asking, but is do commentators here really mean .kml and .kmz files?
I've used the GoogleMap module since its early days, and find it a useful addition. I've never used the previously included 'map' section of PGV, so, for me, it is not required. And, as I need to trim any instance of PGV to 1000 files or less, all the place/flag data gets short shrift.
I also choose my own 'places' - it is quite quick and easy to get co-ords these days, and it gives me some control over what is being shown. So connections to inbuilt tables - even external sites - are not required.
FWIW :-) and a bit off-topic.....
Paul
Australia