* Mapping and Geocoding Woes

[Shiriki]

Hi

Up until now, I have been recording event locations all in the Place field, without too much stucture with comma separated values.
However, I believe the time has come to bite the bullet and rationalise the number of columns in both Place and Address fields to aid sorting of data and portability as recommended elsewhere......
I was thinking of having 3 columns in the Place field and 7 in the address, along the lines that 'Tatewise' uses. However I have had a play with some of my data and have come up against the following issue:
I have a number of events occurring in a similar location (Birth, Residence, Education 1, Education 2) in for example Forest Hill, London, England if I use the 3 column for Place format.
Family Historian puts these 4 events at the generic location of Forest Hill, London, England..
With the Focus on the individual concerned and mapping places just for him and zooming in onto the map pin, I can click on this to see Selected events at this location....all the 4 mentioned above.......so far so good.
However the education events in the Forest Hill, London, England area are a few streets way from the Birth and residence.
I have expanded the Left Hand pane to show all events for this individual and unchecked them all and just checked say Education 1 and manually inserted a more accurate geocode for this one event. Unfortunately all the other events associated with Forest Hill, London, England get changed to this amended geocode.
My question is how does one manually separate one event with known more accurate geocoding information without affecting the others? Am I missing something or will I have to continue with having more information within the Place field (i.e. Full address details) so that the program can distinguish between different events and whilst plotting them all initially at the same location one is able to move the map pins one by one away from this initial location.....
Probably haven't explained this particularly well but any advice would be welcome...

Many thanks in advance

Shiriki

[tatewise]

Shiriki, you are not missing anything.
For each Place name there is only one Place Record, and that is where Lat/Longitude is stored.
You cannot geocode separate Facts that all share the same Place name.

That leaves many of us with a dilemma:
Do we stick with years of GEDCOM custom & practice with Place and Address details separate, but limited geocode Mapping?
OR
Do we move some of our Address details into Place fields just to get better geocode Mapping?

One thing to recognise is the FH Edina geocoder is not currently very good at geocoding detailed addresses, because it is only intended to geocode large places.

It is complicated by many of us recording Place names using historical names as on Certificates, etc, rather than modern names, whereas the Edina geocoder only recognised the modern names, which is where the Standardized field comes into play, but a lot may need to be entered.

The only other option is to use the Map Life Facts Plugin that does support both Address and Place fields for every Fact.

[Shiriki]

Many thanks Tatewise for the prompt reply....
A shame that nothing is simple and straightforward on this particular subject.
Hopefully things will evolve and some standardisation will become the norm in the future......
In the meantime I am considering having a lot more information in the Place field even if it duplicates a lot held in the Address in order to overcome the shortcomings of existing geocoding within Family Historian and allow finer placement of 'Map Pins'.
I will have to experiment with my files and also have a go at using plug ins as suggested to see if this is a better alternative to improve the situation (Haven't used any plug ins to date so this will be an education).
It's difficult to make a decision as to what is the best way forward so as to avoid having to modify one's methodology at some future date.....


Shiriki

[tatewise]

Yes, it has become difficult to decide the best way forward.
If you look at recent postings you will see others with the same problem.

One thing to ask yourself is "What do I want to achieve with Map Pins and why?".

I think the idea behind the FH V6 mapping is to just give an indication of where people lived and how they moved around.

[jimlad68]

Shiriki,

There have been quite a few posts on Geocodes and PLACe etc recently, and I suspect many more to come. I suggest you do a search on Geocode and see which topics might help, in particular since FHv6. As Mike says, we might have to rethink our PLACE + ADDRess strategy if we are to take advantage of Geocoding.

[Shiriki]

Hi Again

At present, to improve geocoding I use the following site which seems to give good locations to around street level accuracy if one keys in an address with a street number.

http://gmaps-samples.googlecode.com/svn ... ocode.html

If one is familiar with the area concerned and knows the building or house locations for a particular event/attribute then it is possible to switch to Satellite View, zoom in and relocate the map pin for even greater accuracy and note the new geocode co-ordinates. (Google Street view can also be a useful tool to aid identification).
Armed with this information the intention is to update the geocoding at present held within Family Historian.
Obviously this amount of accuracy can only be applied when one has discovered exact address details (via Birth, Marriage, Death certificates etc), but if it is possible to do so why not?.......it is fascinating to see plotted on a map how ones ancestors moved around locations and perhaps married their spouse who only lived a few doors away and married in a nearby church......albeit in the same general area.
I will have to examine how Individual/Narrative reports appear after tinkering around with the Place and Address fields.
All I can say is thank goodness for this very active forum where ideas and advice can be exchanged.

Albeit slightly late.....A Happy New Year to Everyone!

Shiriki

[PeterR]

There may be a problem in some cases if a user uses the Place field to hold full geographic address details including those often stored only in the Address field or sub-fields. The GEDCOM 5.5 standard has an upper limit of 120 for the length for the text string following the PLAC tag (including commas and spaces). It can be argued that geographic address details for an event should be stored in the Address field or sub-fields; according to the GEDCOM standard, the Place field is about jurisdiction (Registration Sub-districts, Districts, County Authorities, etc.) not about precise geography.

Is there any reason, in principle, why the FH Place record could not contain data from Address as well as from Place fields?

[tatewise]

Currently, Place Records are directly linked to Place fields, so cannot hold Address details unless you add them to the Standardized field, but only one such entry is allowed and is also limited to 120 chars.

It would need a redesign to add say Address Records directly linked to Address fields, which when geocoded could take the associated Place field into account.

[jimlad68]

I was surprised at the "upper limit of 120 for the length for the text string following the PLAC tag ....", I checked my own data and only found 1 entry near that, so I experimented and made it much longer. FH seems to save and reload it OK. Is this one of those restrictive Gedcom standards that is ignored by common consent, or would we likely have problems with other programs/online.

[tatewise]

All GEDCOM tags are governed by a length specification.
The long multi-line text fields such as any Note and Text From Source get around it by allowing CONTinuation and CONCatenation tags.

However, the length specification is complex:

The total length of a GEDCOM line, including leading white space, level number, cross-reference
number, tag, value, delimiters, and terminator, must not exceed 255 (wide) characters.

Whereas individual fields are also restrained:

The field sizes show the minimum recommended field length within a database that is constrained to
fixed length fields.

For example the PLACe field defines:

PLACE_VALUE:= {Size=1:120}

So, the minimum recommended length is 120 chars, but there is nothing to stop it extending to about 247 chars (i.e. 255 - level - tag - terminator).
In other words the smallest PLACe field that must be supported is 120 chars.
So, the maximum length that is certain to be portable is 120, but most programs allow more.