* Best format of PLACe and ADDRess for Map Geocoding
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Best format of PLACe and ADDRess for Map Geocoding
I've a busy few months ahead but I have just had time to install FHv6 and it is looking very nice.
But with the new mapping features it has immediately prompted me to look again at my PLACe and ADDRess structure to make it fit in with the latest format that ties in with geocoding.
<> Is there a best "format" for geocoding to understand?
- Does anyone know of a link?
- Has anyone found out by trial and error?
<> How does FH look for a geocode place?
I suspect it first checks for a Standardized version.
If none it just passes whatever it finds in PLACe
Does it also look at ADDRess?
If the whole address is in PLACe, does that confuse the geocoding?
Is it best to treat England as a "state" and UK as the country, even leave England out altogether (after all the counties are unique with the UK)?
Does a post code confuse the geocoding?
<> I also notice the default format for the geocode is Deg-Min-Sec whereas many applications seem to use Deg/N/S/E/W or Deg +- or just Deg (360), and I find the latter2 much easier with copy/paste.
I've noticed this in a previous post which is great for looking up older place names.
http://gazetteer.org.uk/
I have also had a look at the Edina website but can't find anything obvious there
http://edina.ac.uk/
But with the new mapping features it has immediately prompted me to look again at my PLACe and ADDRess structure to make it fit in with the latest format that ties in with geocoding.
<> Is there a best "format" for geocoding to understand?
- Does anyone know of a link?
- Has anyone found out by trial and error?
<> How does FH look for a geocode place?
I suspect it first checks for a Standardized version.
If none it just passes whatever it finds in PLACe
Does it also look at ADDRess?
If the whole address is in PLACe, does that confuse the geocoding?
Is it best to treat England as a "state" and UK as the country, even leave England out altogether (after all the counties are unique with the UK)?
Does a post code confuse the geocoding?
<> I also notice the default format for the geocode is Deg-Min-Sec whereas many applications seem to use Deg/N/S/E/W or Deg +- or just Deg (360), and I find the latter2 much easier with copy/paste.
I've noticed this in a previous post which is great for looking up older place names.
http://gazetteer.org.uk/
I have also had a look at the Edina website but can't find anything obvious there
http://edina.ac.uk/
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- tatewise
- Megastar
- Posts: 28409
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Checkout the Help for the Map Window and the Place Property Box (click F1 with either of those windows open).
Most of your questions are answered therein.
The details of what formats work best and what don't is still a bit vague.
It does NOT look at ADDRess fields, and it has been suggested that the Edina geocoder does not hold that much fine detail.
Lat/Longitude is supported in four popular formats.
When we know more there will probably be a KB advice page or two on the subject.
Most of your questions are answered therein.
The details of what formats work best and what don't is still a bit vague.
It does NOT look at ADDRess fields, and it has been suggested that the Edina geocoder does not hold that much fine detail.
Lat/Longitude is supported in four popular formats.
When we know more there will probably be a KB advice page or two on the subject.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
Re: Best format of PLACe and ADDRess for Map Geocoding
The advice in the reply to my post Places and Addresses - best practice (11868) proved helpful as I too wanted to get my modest 300 or so unique places tidied up. Geocoding them I have had a 100% success rate with no noticeable errors.
Thanks.
Thanks.
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
I've now had chance to play around with PLACes with the new FH Map feature and also Map Life Facts.
<> Observations:
- FH seems to ignore ADDRess data and just use the PLACe info, but seems to expect it only to contain Town/City, State, Country details. I have setup my PLACe data not to use ADDRess, i.e. all the info in the PLACe comma separated fields. This is how I used it in TMG and am very happy with this, especially as I use the ADDRess fields for something else (abbreviated places to have less clutter in diagrams).
Hence the extra detail in my PLACe data seems to confuse FH and the results are not very good.
- Map Life Facts does a much better job, however it (really Google Maps) has a problem where there is a House name or similar (Church name etc).
However, if the order of details is reversed e.g.
from "72 Turpin Green Lane-Stelson House, Leyland, Lancashire, , England"
(or if Stelson house is inserted anywhere, but if Stelson House is removed there is no problem)
to "England, , Lancashire, Leyland, Turpin Green Lane, 72, Stelson House"
(or most variations for street+number, as long as the house name is at the end)
There is no problem.
Interestingly, Bing and HERE (same stable) maps had no problem, they just ignored the Stelson house. Is there a lesson here that Google is not always best, but I have no idea if the Bing API is any better.
- I still like the TMG method of keeping lat/long details in one of the PLACe fields, and is therefore also completely Gedcom standard. However I do appreciate that "data" is moving on and that the addition of a "standardised" place option gives the ability to keep the original Place name but with a modern geographic reference. It also looks like both standardised place and lat/long are becoming partially portable between programs. I've not checked to see how easy it is to use either or both in FH reports/diagrams.
<> So this then begs the question whether I should change my PLACe structure to be biggest first. i.e. Country, State, Town/City, Street, #, any other detail. To me this is actually far more logical and it also makes sorting much easier. This is similar to the date argument where I like to use YMD over the UK DMY and USA MDY.
<> I am sure there would be downsides to this, especially as most other Genealogy programs would be expecting street > > > Country order.
Has anyone else looked at this and found any problems?
<> The next question is of course, does anyone know of a routine, either within or external to FH, of file manipulation to swap around the comma separated fields. I have no doubt that this might be useful for anyone migrating programs or simply reshuffling their PLACe or ADDRess fields. For TMG there is an option in TMG Utility to do this by repeatedly copying 1 field at a time:
http://www.johncardinal.com/tmgutil/cha ... eparts.htm
<> Observations:
- FH seems to ignore ADDRess data and just use the PLACe info, but seems to expect it only to contain Town/City, State, Country details. I have setup my PLACe data not to use ADDRess, i.e. all the info in the PLACe comma separated fields. This is how I used it in TMG and am very happy with this, especially as I use the ADDRess fields for something else (abbreviated places to have less clutter in diagrams).
Hence the extra detail in my PLACe data seems to confuse FH and the results are not very good.
- Map Life Facts does a much better job, however it (really Google Maps) has a problem where there is a House name or similar (Church name etc).
However, if the order of details is reversed e.g.
from "72 Turpin Green Lane-Stelson House, Leyland, Lancashire, , England"
(or if Stelson house is inserted anywhere, but if Stelson House is removed there is no problem)
to "England, , Lancashire, Leyland, Turpin Green Lane, 72, Stelson House"
(or most variations for street+number, as long as the house name is at the end)
There is no problem.
Interestingly, Bing and HERE (same stable) maps had no problem, they just ignored the Stelson house. Is there a lesson here that Google is not always best, but I have no idea if the Bing API is any better.
- I still like the TMG method of keeping lat/long details in one of the PLACe fields, and is therefore also completely Gedcom standard. However I do appreciate that "data" is moving on and that the addition of a "standardised" place option gives the ability to keep the original Place name but with a modern geographic reference. It also looks like both standardised place and lat/long are becoming partially portable between programs. I've not checked to see how easy it is to use either or both in FH reports/diagrams.
<> So this then begs the question whether I should change my PLACe structure to be biggest first. i.e. Country, State, Town/City, Street, #, any other detail. To me this is actually far more logical and it also makes sorting much easier. This is similar to the date argument where I like to use YMD over the UK DMY and USA MDY.
<> I am sure there would be downsides to this, especially as most other Genealogy programs would be expecting street > > > Country order.
Has anyone else looked at this and found any problems?
<> The next question is of course, does anyone know of a routine, either within or external to FH, of file manipulation to swap around the comma separated fields. I have no doubt that this might be useful for anyone migrating programs or simply reshuffling their PLACe or ADDRess fields. For TMG there is an option in TMG Utility to do this by repeatedly copying 1 field at a time:
http://www.johncardinal.com/tmgutil/cha ... eparts.htm
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- tatewise
- Megastar
- Posts: 28409
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Why do you say "FH ... PLACe ... seems to expect it only to contain Town/City, State, Country details."
You can set up to 10 comma separated columns in Tools > Work with Data > Places and similarly Addresses.
However, Town/City, State, Country is a popular format.
Map Life Facts advises in its Help & Advice that house/church names can be enclosed in "string quotes" to exclude them from the Google geocoder. Alternatively, use the Substitute field to hold a Place name that geocodes correctly.
I am not aware of any problems with adding Place details to Reports & Diagrams.
I strongly advise against reversing your Place structure. Tools > Work with Data > Places has good Column sorting and the Reverse Display Order option. Sorting Place Records by Place comma separated parts is also now easy by defining Record Window Columns involving the new =TextPart() function.
In Narrative reports the automatic abbreviation of Place names assumes the popular Town/City, State, Country order.
The =TextPart() function incorporated into a Plugin could offer comma separated part shuffling, but I suspect it would be easier to use the =TextPart() function in Reports, Diagrams, Queries, and sentence Templates to achieve the desired effect.
You can set up to 10 comma separated columns in Tools > Work with Data > Places and similarly Addresses.
However, Town/City, State, Country is a popular format.
Map Life Facts advises in its Help & Advice that house/church names can be enclosed in "string quotes" to exclude them from the Google geocoder. Alternatively, use the Substitute field to hold a Place name that geocodes correctly.
I am not aware of any problems with adding Place details to Reports & Diagrams.
I strongly advise against reversing your Place structure. Tools > Work with Data > Places has good Column sorting and the Reverse Display Order option. Sorting Place Records by Place comma separated parts is also now easy by defining Record Window Columns involving the new =TextPart() function.
In Narrative reports the automatic abbreviation of Place names assumes the popular Town/City, State, Country order.
The =TextPart() function incorporated into a Plugin could offer comma separated part shuffling, but I suspect it would be easier to use the =TextPart() function in Reports, Diagrams, Queries, and sentence Templates to achieve the desired effect.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Mike, thanks for those observations:
<> I say "FH ... PLACe ... seems to expect it only to contain Town/City, State, Country details" because only those PLACes I have with Town/City, State, Country details seem to be most accurate, indeed, extra detail often plots all over the place or at best what looks like a generic placeholder for a town. It could be my name structure, but it is mostly basic. I have noticed it makes it even worse for a place like Wigan if it's old County, say Lancashire ,is cited, wheras with the same data (copied project) with your Map Life Facts and Bing I get much better results, often down to exact street number location.
However, on reflection I am not too worried about this now, as I would expect to at least check the lat/long entries and probably fine tune them.
<> After reading around the web I am even more confused on my way forward. On the one hand I am coming to think that using the historical place name in PLACe, with standardised placename and lat/long info is good. The historical name should help with research while the standardised name will help both geotagging and current geography. However, for portability of data for plotting on future websites or programs, it might be best to use the standardised placename for the PLACe fields, and somehow make reference to the Historical Place Name, and as some point out, the same place could have more than one Historical name which might all be useful for research. I suppose the current standardised placenames will eventually change, so the most important record will always be the lat/long detail.
<> Thanks for the "string quotes" tip, it works much better, still OK in Bing, but not if direct to Google Maps. Yet another consideration for my naming conventions.
<> I must say the integration of Map Life facts into the FH Website/CD/DVD is very impressive.
So, back to the drawing board and thanks again Mike for your comments, and of course Map Life facts.
<> I say "FH ... PLACe ... seems to expect it only to contain Town/City, State, Country details" because only those PLACes I have with Town/City, State, Country details seem to be most accurate, indeed, extra detail often plots all over the place or at best what looks like a generic placeholder for a town. It could be my name structure, but it is mostly basic. I have noticed it makes it even worse for a place like Wigan if it's old County, say Lancashire ,is cited, wheras with the same data (copied project) with your Map Life Facts and Bing I get much better results, often down to exact street number location.
However, on reflection I am not too worried about this now, as I would expect to at least check the lat/long entries and probably fine tune them.
<> After reading around the web I am even more confused on my way forward. On the one hand I am coming to think that using the historical place name in PLACe, with standardised placename and lat/long info is good. The historical name should help with research while the standardised name will help both geotagging and current geography. However, for portability of data for plotting on future websites or programs, it might be best to use the standardised placename for the PLACe fields, and somehow make reference to the Historical Place Name, and as some point out, the same place could have more than one Historical name which might all be useful for research. I suppose the current standardised placenames will eventually change, so the most important record will always be the lat/long detail.
<> Thanks for the "string quotes" tip, it works much better, still OK in Bing, but not if direct to Google Maps. Yet another consideration for my naming conventions.
<> I must say the integration of Map Life facts into the FH Website/CD/DVD is very impressive.
So, back to the drawing board and thanks again Mike for your comments, and of course Map Life facts.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- tatewise
- Megastar
- Posts: 28409
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Within FH the Place name geocoding by Edina is, as you correctly say, not currently intended to map down to street level.
Usually it is recommended that the Place field should not contain that level of Address detail, but (apart from geocoding) FH does support as much detail as you like.
Map Life Facts only does a better job because Google geocoding does map down to street level in many countries (as I suspect does BING), and so the address details outweigh the 'erroneous' historic county, etc.
There has been much debate elsewhere about historical versus modern standardized Place names.
Part of that debate suggested that Edina does geocode postcodes if entered on their own in Standardized, so that might help fix street locations.
But as you say, it also possible to do the geocoding manually by entering Lat/Longitude values.
Portability is an important issue for some. The FH V6 Unicode UTF-16 GEDCOM is not as portable as in earlier versions. Many programs do not even recognise the UTF-16 encoding format, let alone the custom _PLAC records. That is why I wrote the Export Gedcom File Plugin, which not only offers various encodings, but also converts most custom FH tags to standard GEDCOM 5.5 format. For example, Place Records can be converted to Source Records with all the details retained (albeit in Notes, etc) and linked to the Place fields by Citations.
Thank you for the positive feedback regarding the Map Life Facts Plugin.
There will be a new version out soon to fix a few minor problems that have arisen.
Usually it is recommended that the Place field should not contain that level of Address detail, but (apart from geocoding) FH does support as much detail as you like.
Map Life Facts only does a better job because Google geocoding does map down to street level in many countries (as I suspect does BING), and so the address details outweigh the 'erroneous' historic county, etc.
There has been much debate elsewhere about historical versus modern standardized Place names.
Part of that debate suggested that Edina does geocode postcodes if entered on their own in Standardized, so that might help fix street locations.
But as you say, it also possible to do the geocoding manually by entering Lat/Longitude values.
Portability is an important issue for some. The FH V6 Unicode UTF-16 GEDCOM is not as portable as in earlier versions. Many programs do not even recognise the UTF-16 encoding format, let alone the custom _PLAC records. That is why I wrote the Export Gedcom File Plugin, which not only offers various encodings, but also converts most custom FH tags to standard GEDCOM 5.5 format. For example, Place Records can be converted to Source Records with all the details retained (albeit in Notes, etc) and linked to the Place fields by Citations.
Thank you for the positive feedback regarding the Map Life Facts Plugin.
There will be a new version out soon to fix a few minor problems that have arisen.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Mike, if you were looking for suggestions for Map Life Facts, a nice enhancement would be to have dates (or sequence # + date) instead of symbols then connect them with a chronological arrowed line, then 2 or more people with different coloured/style lines on the same map to see if their paths cross. Not even sure if that is possible with Google maps, but from my Fell Running "virtual online recces" more likely with Google Earth. I should imagine that would be quite a tall order though. I have not noticed it on any other genealogy products that do it.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- tatewise
- Megastar
- Posts: 28409
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
I think I will pass on that ~ it sounds far too complex and I am not sure what it would show.
To be of any significance the map would need a time dimension, because the lines may cross geographically, but be quite separate in the time domain.
To be of any significance the map would need a time dimension, because the lines may cross geographically, but be quite separate in the time domain.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
-
- Famous
- Posts: 106
- Joined: 14 Sep 2014 09:59
- Family Historian: V7
Re: Best format of PLACe and ADDRess for Map Geocoding
Thanks for this post. I have started tidying up my locations and didn't realiae about the extra columns. My question is that I now have four columns using the suggested format but an extra one at the beginning for some small villages in a city so something like Coldside, Dundee, Forfarshire [Angus], Scotland. As this isn't common I have a lot of blanks in column 1. Does this matter?
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Not at all, indeed necessary if you want your PLACe info structured. See also the comments and links from gsward » 12 Dec 2014 21:51. It seems so simple, but it is worth giving some thought to how you want to use your place/address info so as to best structure it. Even after all these years there is no real standard even further complicated with lat/long and standardised places. This is a good starting point as it gives links to other discussions, going back many years!
http://www.geneamusings.com/2010/11/sta ... in-my.html
http://www.geneamusings.com/2010/11/sta ... in-my.html
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
I have been playing around some more with various ideas for storing my PLACe info in the light of Geocoding. I hope this does not sound too unwieldy as I've rewritten it so many times in light of testing and new info.
So I would be very pleased to hear of any comments or drawbacks to this idea, any other links etc and especially if anyone else has dabbled with moving Places/ Geocodes between programs or online.
<> Idea 1 (failed but interesting):
- Use the PLACe for the modern Standardized detail only. This is so that the data is friendly to FH geocoding (via Map Life Facts) and most portable if input to other programs.
- Add a NOTE for the standard PLACe (not the note in the new FH geocode Gedcom Extensions). This would include the historical address. This could also include any other notes and addresses with dates at this location which might also help in research, even lat/long.
BUT: An interesting observation:
If you:
- create a note for a PLACe via the ALL tab.
- then change the place via the drop down > Place List
- the note stays the same, IT DOES NOT COPY THE NOTE FOR THE NEW PLACE.
Is this by design or wrong or just not thought about because it is unusual?
However, I am not too concerned as I have discounted this, as although theoretically Gedcom correct, of the tests I did, only Rootsweb Trees (as ever) seems to display the note in a "meaningful" Gedcom way.
In addition even FH did not show the PLACe note along with other notes in reports. Perhaps I need to report this as an error or should it be added to Issues for Calico Pie to consider for FH6 updates.
<> Idea 2 (failed but interesting):
- My new best genealogical friend; Sources. Instead of using a note to the PLACe record, use a Source. However, this gave similar problems to adding a note to the PLACe record. If I changed the PLACe, it did not change the Source that went with it, and did not show in reports when other notes did.
<> Idea 3 (looking good):
- Still with sources, but instead create a Source with details about the PLACe record(s) as before, but add that to the event rather than the PLACe. Works a treat, is no more trouble, more flexible, is fully Gedcom and exports easily. One source could also be used for say for a street used for multiple PLACes, even showing some history.
<> So where now. My current thinking is:
- I feel leveraging of our genealogical geocode data will get better in the near future; Geographic Timelines, did people's paths cross etc. To be ready for this the PLACe data needs to be portable. Whilst I fully understand why FHs v6 has used its new geocode place records they are not portable enough for me.
At present portability seems to rest with having a PLACe name that is understood by as many applications as possible as there is no standard for transferring lat/long (see also previous posts in this topic), hence using Standardized names. As an aside, Map Life facts is more likely to get an accurate lat/long via Google Maps than the built in FH Maps.
However, I don't want to loose historic place information. The more I have looked at this, the more I feel "places" have not had their due respect in genealogy, mostly just the name of a place and any extra detail is tied up with the fact/event rather than the place. Places may have had many different names, street numbers changed or other historic detail.
- So how to do this as simply and as portably as possible; use idea 3 above:
Where required for clarification or just extra information, create a source with a name that mirrors the Standardized name like:
place>6, Bent Lane, Leyland, Lancashire, England (or for easier sorting place>England, Lancashire, Leyland, Bent Lane, 6)
or for a whole street:
place>Bent Lane, Leyland, Lancashire, England
Link this to the fact/event (n.b. linking to the PLACe does not report easily in FH and portability is limited).
<><> Extra points re geocoding:
<> For info, I put all my location data in the PLACe record, none the ADDRess. This means that Map Life Facts returns much better Geocoding results.
<> I was hoping to convert my PLACe records for the highest level downwards e.g.
England, , Lancashire, Leyland, Turpin Green Lane, 72,
however, although you would think this more logical for Google and Bing maps, it does in fact do much worse than the other way around; e.g. the usual street, town, county, country; pity.
<> The structure of the PLACe record I found for best geocoding (I suppose = Standardized Place name). This is for FH with Map Life Facts or direct into Google or Bing maps.
- The usual:
72, Turpin Green Lane, Leyland, Lancashire, England
works fine.
None of these Geocoders like "extra" nonaddress information, it seems to confuse them unless it is already known to their map. Items such as a House Name or a building name that no longer exists.
If you want to add a house name it gets confused, but this format often ignores the house name, the - (minus) and phrase in quotes with a blank after seems to be important. (In the long term I am not sure how other genealogy programs would cope though). e.g.
-"Stelson House" , 72, Turpin Green Lane, Leyland, Lancashire, England
However in this case the Stelson House could be part of the Source record.
For items like churches that are still there, try and find the exact way it is stored by the map program. But occasionally this can be problematic. e.g.
for this example google is
Leyland Methodist Church, Turpin Green Lane, Leyland, Lancashire, England
for Bing it is
Turpin Green Leyland Methodist Church, Goulding Avenue, Leyland, Lancashire PR25 3HE
If you try to put a house number in can help and sometimes also the - (minus) for the Church name: e.g.
-"Leyland Methodist Church" , 25, Turpin Green Lane, Leyland, Lancashire, England
The point of the -"text text" is to keep the detail with your PLACe record for FH Reports etc and to make it easy to Geocode. It may also mean shuffling up your PLACe fields by 1.
So I would be very pleased to hear of any comments or drawbacks to this idea, any other links etc and especially if anyone else has dabbled with moving Places/ Geocodes between programs or online.
<> Idea 1 (failed but interesting):
- Use the PLACe for the modern Standardized detail only. This is so that the data is friendly to FH geocoding (via Map Life Facts) and most portable if input to other programs.
- Add a NOTE for the standard PLACe (not the note in the new FH geocode Gedcom Extensions). This would include the historical address. This could also include any other notes and addresses with dates at this location which might also help in research, even lat/long.
BUT: An interesting observation:
If you:
- create a note for a PLACe via the ALL tab.
- then change the place via the drop down > Place List
- the note stays the same, IT DOES NOT COPY THE NOTE FOR THE NEW PLACE.
Is this by design or wrong or just not thought about because it is unusual?
However, I am not too concerned as I have discounted this, as although theoretically Gedcom correct, of the tests I did, only Rootsweb Trees (as ever) seems to display the note in a "meaningful" Gedcom way.
In addition even FH did not show the PLACe note along with other notes in reports. Perhaps I need to report this as an error or should it be added to Issues for Calico Pie to consider for FH6 updates.
<> Idea 2 (failed but interesting):
- My new best genealogical friend; Sources. Instead of using a note to the PLACe record, use a Source. However, this gave similar problems to adding a note to the PLACe record. If I changed the PLACe, it did not change the Source that went with it, and did not show in reports when other notes did.
<> Idea 3 (looking good):
- Still with sources, but instead create a Source with details about the PLACe record(s) as before, but add that to the event rather than the PLACe. Works a treat, is no more trouble, more flexible, is fully Gedcom and exports easily. One source could also be used for say for a street used for multiple PLACes, even showing some history.
<> So where now. My current thinking is:
- I feel leveraging of our genealogical geocode data will get better in the near future; Geographic Timelines, did people's paths cross etc. To be ready for this the PLACe data needs to be portable. Whilst I fully understand why FHs v6 has used its new geocode place records they are not portable enough for me.
At present portability seems to rest with having a PLACe name that is understood by as many applications as possible as there is no standard for transferring lat/long (see also previous posts in this topic), hence using Standardized names. As an aside, Map Life facts is more likely to get an accurate lat/long via Google Maps than the built in FH Maps.
However, I don't want to loose historic place information. The more I have looked at this, the more I feel "places" have not had their due respect in genealogy, mostly just the name of a place and any extra detail is tied up with the fact/event rather than the place. Places may have had many different names, street numbers changed or other historic detail.
- So how to do this as simply and as portably as possible; use idea 3 above:
Where required for clarification or just extra information, create a source with a name that mirrors the Standardized name like:
place>6, Bent Lane, Leyland, Lancashire, England (or for easier sorting place>England, Lancashire, Leyland, Bent Lane, 6)
or for a whole street:
place>Bent Lane, Leyland, Lancashire, England
Link this to the fact/event (n.b. linking to the PLACe does not report easily in FH and portability is limited).
<><> Extra points re geocoding:
<> For info, I put all my location data in the PLACe record, none the ADDRess. This means that Map Life Facts returns much better Geocoding results.
<> I was hoping to convert my PLACe records for the highest level downwards e.g.
England, , Lancashire, Leyland, Turpin Green Lane, 72,
however, although you would think this more logical for Google and Bing maps, it does in fact do much worse than the other way around; e.g. the usual street, town, county, country; pity.
<> The structure of the PLACe record I found for best geocoding (I suppose = Standardized Place name). This is for FH with Map Life Facts or direct into Google or Bing maps.
- The usual:
72, Turpin Green Lane, Leyland, Lancashire, England
works fine.
None of these Geocoders like "extra" nonaddress information, it seems to confuse them unless it is already known to their map. Items such as a House Name or a building name that no longer exists.
If you want to add a house name it gets confused, but this format often ignores the house name, the - (minus) and phrase in quotes with a blank after seems to be important. (In the long term I am not sure how other genealogy programs would cope though). e.g.
-"Stelson House" , 72, Turpin Green Lane, Leyland, Lancashire, England
However in this case the Stelson House could be part of the Source record.
For items like churches that are still there, try and find the exact way it is stored by the map program. But occasionally this can be problematic. e.g.
for this example google is
Leyland Methodist Church, Turpin Green Lane, Leyland, Lancashire, England
for Bing it is
Turpin Green Leyland Methodist Church, Goulding Avenue, Leyland, Lancashire PR25 3HE
If you try to put a house number in can help and sometimes also the - (minus) for the Church name: e.g.
-"Leyland Methodist Church" , 25, Turpin Green Lane, Leyland, Lancashire, England
The point of the -"text text" is to keep the detail with your PLACe record for FH Reports etc and to make it easy to Geocode. It may also mean shuffling up your PLACe fields by 1.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
-
- Famous
- Posts: 106
- Joined: 14 Sep 2014 09:59
- Family Historian: V7
Re: Best format of PLACe and ADDRess for Map Geocoding
Wow that is a lot to digest and I'm not sure of the answer. I have decided that I will use address for the house name and street address.The place I have four fields. So Town 1, Town 2, County, Country. I keep the place fairly close to the historic address so one ancestor was born Kingsand, Devon and died Kingsand, Cornwall. So I have this in twice (, Kingsand, Cornwall, England etc) and then for the source I transcibe the exact text in the "Text from Source" so if they have abbreviated the address or left bits out then this is where I have this. I haven't checked the maps since I cleansed my addresses but hoping I should work. My family are world wide so not using the address wont be a problem. My husband's family are all from the same area so the streets would be useful.
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
BK, yes it is all one big compromise at the moment, especially as everyone is doing their own thing re geocoding. I did think of using PLACe for street #, street > country and then ADDress for details that would not go well with geocoding. That would have best of both worlds, geocoding outside of FH and detail like old churches etc within FH. But I have never felt that ADDReses migrate well between programs, so for me it would be throwing the baby out with the bathwater, indeed TMG where I came from did not use the equivalent ADDR at all, and just exported 10 place parts via the Gedcom PLACe record. At present I am using ADDRess for a PLACe abbreviation with a modified routine I got from Mike T. I can use it in diagrams to save space.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
-
- Famous
- Posts: 106
- Joined: 14 Sep 2014 09:59
- Family Historian: V7
Re: Best format of PLACe and ADDRess for Map Geocoding
Just out of interest, what programs are you referring to? I just use FH and then manually update my tree on ancestry. (Just being nosey)
- tatewise
- Megastar
- Posts: 28409
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Jim, the gist of your proposal is largely the same as the how_to:create_locations_database_details|> Create a Locations Database of Place & Address Details.
My Map Life Facts Plugin can support that concept by setting is Preferences to save Database In: Source &/or Repository. At the same time it can synchronise with Place Records and there is an option to copy these Place Record details to the Source/Repository version. A WORD OF CAUTION: BillH and I have been testing this Plugin recently and there are a few glitches that have been fixed and will appear in the Plugin Store next week.
On the portability point, the Export Gedcom File Plugin can convert Place Records to Source Records cited by the Place fields. This is needed even to export to FH V5 Projects, but TNG accepts the Place Records almost as they are. Other options would be feasible if felt necessary.
My Map Life Facts Plugin can support that concept by setting is Preferences to save Database In: Source &/or Repository. At the same time it can synchronise with Place Records and there is an option to copy these Place Record details to the Source/Repository version. A WORD OF CAUTION: BillH and I have been testing this Plugin recently and there are a few glitches that have been fixed and will appear in the Plugin Store next week.
On the portability point, the Export Gedcom File Plugin can convert Place Records to Source Records cited by the Place fields. This is needed even to export to FH V5 Projects, but TNG accepts the Place Records almost as they are. Other options would be feasible if felt necessary.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
BK, I know a few people update different trees manually, but that is the last thing I want to do, it takes me all my time to key up my wife's research (in fact way way behind), hence my desire for portability if I need the data elsewhere. At present, my main other programs/online, when I get around to it, are Rootsweb Trees (as in my link below), Ancestry online trees (I just import Gedcom), FTM 2014 (I am experimenting with their geocoding which is supposed to mirror the new FamilySearch Standardized Place names, not to be confused with best format for Google or Bing maps), Rootsmagic have a Geocode program. I suspect there will be many more in the future. Now I have FH I hope to take advantage of the web creation tool to either send to people or find somewhere to host and direct people there from say Rootsweb or Ancestry. Hence only key my data once.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Mike, thanks for the FHUG link which I had looked at but was a bit too detailed/structured for my needs, I wish I had that much detail or the time to key it. But the Source principle is very helpful. I think the "Export Gedcom File" or similar will be almost a necessity in future to save lots of data manipulation in other programs/online.
I try to use your Map Life Facts without the Smart Geocoding and region base off, then amend my place to try and get a good result. I hope that that will make it more portable if I use it in other places. Although I can the great benefit of it in the short term.
One thing that has struck me yet again, and mentioned by many in this forum, is that it is one thing using the Gedcom standard, but we rely on a program to interpret/ report on it, and even FH has limitations; on reports in particular. So for me it seems important to take care in data structure in order to use the data both within and without FH. But I don't want to be a slave to portability, as for instance I will almost certainly use the new FHv6 lat/long Places, which as you point out can be converted on export.
Another aspect I have not studied yet is the FamilySearch Standardized Place names, and I suppose this should be where their "FamilySearch Family Tree certified synchronization" comes in, but I have no idea how or if this fits in with Geocoding with sites like Google or Bing maps.
https://familysearch.org/family-trees
https://help.familysearch.org/kb/UserGu ... laces.html
etc
If we thought there were problems with Genealogical standards, at present it seems that geocoding is still every man for himself. Hence my earlier thoughts "a routine, either within or external to FH, of file manipulation to swap around the comma separated fields" and of course routines like Export Gedcom File.
I try to use your Map Life Facts without the Smart Geocoding and region base off, then amend my place to try and get a good result. I hope that that will make it more portable if I use it in other places. Although I can the great benefit of it in the short term.
One thing that has struck me yet again, and mentioned by many in this forum, is that it is one thing using the Gedcom standard, but we rely on a program to interpret/ report on it, and even FH has limitations; on reports in particular. So for me it seems important to take care in data structure in order to use the data both within and without FH. But I don't want to be a slave to portability, as for instance I will almost certainly use the new FHv6 lat/long Places, which as you point out can be converted on export.
Another aspect I have not studied yet is the FamilySearch Standardized Place names, and I suppose this should be where their "FamilySearch Family Tree certified synchronization" comes in, but I have no idea how or if this fits in with Geocoding with sites like Google or Bing maps.
https://familysearch.org/family-trees
https://help.familysearch.org/kb/UserGu ... laces.html
etc
If we thought there were problems with Genealogical standards, at present it seems that geocoding is still every man for himself. Hence my earlier thoughts "a routine, either within or external to FH, of file manipulation to swap around the comma separated fields" and of course routines like Export Gedcom File.
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68
Re: Best format of PLACe and ADDRess for Map Geocoding
I don't know if everyone is aware of an - almost- new field in the Place record.
It's the Standardized Version field.
FH help says:
"... However, if the Standardized field is not blank, geocoding will be based on it instead. Some historical names may not be recognised, or may be incorrectly geocoded. In this situation, you can either simply specify the correct latitude and longitude yourself; or you can supply a modern, standardized name which will be correctly geocoded.
Kindly
Jens Erik
It's the Standardized Version field.
FH help says:
"... However, if the Standardized field is not blank, geocoding will be based on it instead. Some historical names may not be recognised, or may be incorrectly geocoded. In this situation, you can either simply specify the correct latitude and longitude yourself; or you can supply a modern, standardized name which will be correctly geocoded.
Kindly
Jens Erik
- jimlad68
- Megastar
- Posts: 921
- Joined: 18 May 2014 21:01
- Family Historian: V7
- Location: Sheffield, Yorkshire, UK (but from Lancashire)
- Contact:
Re: Best format of PLACe and ADDRess for Map Geocoding
Jens, apologies for taking time to reply, but I was just experimenting with this.
You are very correct in what you say, but one of the factors of this post was portability of the geocoding data.
I fully understand why FH6 uses its new Places system for geocoding in the current geocoding environment. However, the way it stores the extra Place detail with Standardized field and lat/long coordinates does not lend itself to communication with other programs/web products. But then again, no programs do at present, hence my efforts to design my PLACe data such that it fits best with "any/most" programs. Furthermore, the new FH automatic geocoding only goes down to the "District/Village/Town/City , State , Country" details, although this can be extended manually or with Map Life Facts Plugin.
Please look at this topic, especially the entry by jimlad68 » 28 Mar 2015 17:43
Rearrange Address and Place Parts Plugin (12330)
You are very correct in what you say, but one of the factors of this post was portability of the geocoding data.
I fully understand why FH6 uses its new Places system for geocoding in the current geocoding environment. However, the way it stores the extra Place detail with Standardized field and lat/long coordinates does not lend itself to communication with other programs/web products. But then again, no programs do at present, hence my efforts to design my PLACe data such that it fits best with "any/most" programs. Furthermore, the new FH automatic geocoding only goes down to the "District/Village/Town/City , State , Country" details, although this can be extended manually or with Map Life Facts Plugin.
Please look at this topic, especially the entry by jimlad68 » 28 Mar 2015 17:43
Rearrange Address and Place Parts Plugin (12330)
Jim Orrell - researching: see - but probably out of date https://gw.geneanet.org/jimlad68