* Map Life Facts

[Ron Melby]

mike,

As I am typing in the API Key that I got, and copied from Google, I am getting invalid character ( - is the problem, my key contains two) done by copy and paste and hand keying, same results, I save my "valid" key parts, come back in..denied, open the javascript console...which I have no idea how to do.

when I paste it into the table by hand, to prove it correct, everything is ok.

I wasn't sure if this should go on the original thread or not, so I made new, but if it belongs there please attach it there.

Ron

[tatewise]

Hi Ron, sorry about those problems.

To reach the Google Cloud Platform Console first return to the Plugin Help & Advice pages for Manage Quota Limits.
There are several links there to the Google Cloud Platform Console.
To open one of them in your preferred browser use right-click Copy shortcut and Paste into browser address bar.
(Otherwise if you simply click the link it will probably open in the IE browser by default and won't work.)
It should be https://console.cloud.google.com/ which you should bookmark as a favourite.
You may need to login with your Google Account

The Plugin assumes that valid API Keys only contain alphanumeric characters (A-Z, a-z, 0-9) and underscore ( _ ).
What other characters are appearing in your API Key that I need to allow the Plugin to accept?

[Ron Melby]

the negative sign, I have two of them in my key. It shows properly and operates properly once in the table, so it is just the entry. Not a big deal really. I dont think google is going to give you the rules for api keys, and you will have to discover what is allowed as time passes.

I find no javascript console at google cloud.

[tatewise]

OK, I can add negative signs to the set of allowed characters in the next version of the Plugin.
I will actually allow all the Unreserved URI symbols - . _ ~ hyphen, period, underscore, and tilde.

I assumed you wanted to reach the Google Cloud Platform for APIs and Services to manage your API Key.
Visit https://console.cloud.google.com/ and make sure you are logged in to your Google Account.
That should display the Dashboard for your Project.
If necessary use the hamburger Navigation menu top left and choose APIs and Services > Dashboard or click Go to APIs overview in the centre.
On the left should be Dashboard, Library & Credentials so select Credentials.
That will show your API Key and on the right click the pen to Edit API Key.
There you can manage the API Key in various ways.
See plugins:help:map_life_facts:get_personal_api_key|> Map Life Facts ~ Get Personal API Key for advice and screenshots of some of the above.

OR maybe you were looking for something else?

Documentation can be found at https://developers.google.com/maps/documentation/.
Scroll down for links to Maps JavaScript API or Geocoding API, etc...

[Ron Melby]

I have included the actual lines <with snips> from my great grandfathers record. I was so proud, 2348 [Addr] ~ [Place] locations, and it could not find 2. However, I am (because I know this one well) running into a great number of mis-locations, I have my Places set up this way:

city/town/village , township (*PLSS if known), County, State, Country

* https://nationalmap.gov/small_scale/a_plss.html

(T156NR39W) (S24) would describe:
That (T)ownship that is the 156th township (N) of the base meridian (5 in my case, not of concern here)
and (R)ange(s) 39 Townships West of the center point of the base meridian
(S)ection 24 within that township. (I could further divide but do not at present)

they were farmers as most of my relations were.

therefore the best part of my PLAC records will be missing the first division and described by "<blank>,"
it does a good job of locating the Espelie entry since there was a town there (situated in Espelie, but has been gone for at least 75 years.

the rub is, that there is a town called wabasha in wabasha county as well as a township, all coinciding, a town called zumbro and a township called zumbro (they do not coincide) and a township called Valley in Marshall county, And a town called Marshall in Minnesota and as it stands the locations do not locate correctly. I would like to locate it to the township at least, when city is absent. How can I format my places so they locate correctly and do I wrap TRS from PLSS in [ ] to ignore or? can I get some guidance please, on how to do this?

0 @I46@ INDI
1 NAME George Clarence /Hook/
2 NSFX Sr.
1 SEX M
1 BIRT
2 DATE 24 MAR 1869
2 PLAC Bethersden, Kent, Kent, EN, GBR
2 SOUR @S1900@
3 PAGE B, Sheet 3, Dwelling 54, Family 55
1 CHR
2 DATE 15 AUG 1869
2 PLAC Ebony, Kent, Kent, EN, GBR
1 DSCR brown eyes
1 CENS
2 DATE 1871
2 PLAC Wittersham, Kent, Kent, EN, GBR
1 IMMI
2 DATE 25 APR 1871
2 PLAC New York, , New York, NY, USA
2 SOUR @S24@
1 RESI
2 DATE FROM 1871 TO 1912
2 PLAC , , Wabasha, MN, USA
1 CENS
2 DATE 22 JUN 1880
2 PLAC , Zumbro, Wabasha, MN, USA
2 SOUR @S7@
3 PAGE 17, EnumDist 185
1 CENS
2 DATE 1885
2 PLAC , Zumbro, Wabasha, MN, USA
1 RELI Lutheran
1 CENS
2 DATE 18 JUN 1900
2 PLAC , Mazeppa (T109NR14W), Wabasha, MN, USA
1 CENS
2 DATE 1905
2 PLAC , Zumbro, Wabasha, MN, USA
1 CENS
2 DATE 19 APR 1910
2 PLAC , Zumbro, Wabasha, MN, USA
1 RESI
2 DATE 1912
2 PLAC , Valley (T156NR39W), Marshall, MN, USA
2 SOUR @S2011@
3 PAGE 684
1 OCCU Road work
2 DATE FROM 1914 TO 1926
1 OCCU Farmer
2 DATE FROM 1918 TO 1963
1 CENS
2 DATE 1920
2 PLAC , Espelie, Marshall, MN, USA
1 RESI
2 DATE FROM 1928 TO 1 APR 1963
2 PLAC , Valley (T156NR39W), Marshall, MN, USA
2 NOTE 3.5 miles West of Grygla
1 CENS
2 DATE 1930
2 PLAC , Valley (T156NR39W), Marshall, MN, USA
2 NOTE 3.5 miles West of Grygla
1 DEAT
2 DATE 1 APR 1963
2 PLAC Roseau, , Roseau, MN, USA

[tatewise]

As you no doubt have already guessed the PLSS codes are interfering with the Google Maps Geocoder.
(I had a quick look to see if Google Maps recognises PLSS codes in some format, but without success.)

The way to hide the PLSS codes from the geocoder is to enclose them in "string quotes" or [[square brackets]].
e.g. "T156NR39W" or [[T156NR39W]] or perhaps "(T156NR39W)"

Note that FH [[privacy]] brackets in Place names are NOT handled by Diagram & Report options to Inc. [[private]] Notes so the "T156NR39W" format probably looks neatest.

BTW: To avoid upsetting Place records do NOT use the FH Find and Replace to make that change.
When you have decided which PLSS format you prefer, I can talk you through how to use the Search and Replace Plugin.

If after those changes, there are still geocoder positional errors, then there are several workaround techniques.
They are described in the Help & Advice at plugins:help:map_life_facts:1_geocode_location_plots#manage_location_plots|> Manage Location Plots.

These can be rectified by altering your GEDCOM data, by entering an alternative Substitute location, by manually setting Latitude & Longitude values, by nudging with N S E W buttons, or dragging the Marker.

If none of those work for you then let me know.

[Ron Melby]

Alright, first I have restricted it to address long text and place records
searched for (

did not find anything I wasnt looking for
did not find anything in ADDR records and didnt expect to

is there a way to do it in one fell swoop or do I do
F: {
R: "(

and same for close?

no, that will get me ""[ I need a magic thing here don't I?

[tatewise]

OK, so you want to enclose all bracketed PLSS such as (T156NR39W) in string quotes such as "(T156NR39W)".

I suggest you take at least a GEDCOM small Backup beforehand.

Place records need careful handling as explained in plugins:help:search_and_replace:usage_examples#place_name_changes_in_fh_v6|> Place Name Changes in FH V6.

In the Search and Replace Plugin set the following on the Major Options tab:
Select LUA Pattern Mode top right.
Set Search Scope to Place Records (_PLAC).
Set Basic Filters to tick Place fields only with all other fields clear.

In the Search box enter (%b()) which ( captures ) anything %bracketed in a pair of parentheses ( ... )
In the Replace box enter "%1" which surrounds whatever was captured %1 in string quotes " ... "

Finally use Search & Replace.

[Ron Melby]

it put 2 sets of quotes around it. ""(T197NR39W)""

[tatewise]

I would only do that if the Replace box had ""%1"" or that "(T197NR39W)" already had string quotes before running Plugin, or you have run the Plugin twice.
Are you saying that absolutely every such PLSS code has double quotes?
I have run the settings I gave you and it worked fine.

Did you check several Replacement Value: dialogues to check it was working correctly before removing the Confirm every item found option?

Please post a screenshot of your Search and Replace Plugin Major Options tab settings so I can review them.

If it really has gone globally wrong, then revert to the Backup that I advised you to take beforehand.

[Ron Melby]

yes, every one.

when I did the following
F: [
R: "[
it did the same as well


so, I have went into my word processor, found "" replaced with " and its fine.

I will send you a screen shot when I get home. Just letting you know I have seen this.

[Ron Melby]

cant paste screen shot here larger than 256 bytes

and cant copy items from the page, so...


(%b[]) lua pattern mode
"%1"
Place Fields
Alpha

it has raised havoc with one of my plugins (maybe more, dont know yet)
but remember where I was doing:

USA.MN.VALLEY
GBR.EN.KENT
if there is a csv
VALLEY "" <<< of any kind in it, it doesnt see it, have to see what that is.

[Ron Melby]

Found the error, in my records, @_PLAC records, when you fix something, do not respect leading blanks.

[tatewise]

I don't understand what problems you are talking about, please give a clearer description.

Anyway, I had no problem with 36 KB Snipping Tool screenshot shown below, so how do you capture screenshots?
See info:forums#posting_topics|> Posting Topics for tips.

Does your Search and Replace 2.9 have Major Options tab looking exactly as shown below?
When you click Search & Replace does dialogue look like the one below?
Note that the Current Value: has no string quotes and red arrowed Replacement Value: has only a single pair.
That is confirmed in the final Result Set by the Old Value and New Value columns.

A little experiment proved that you DID NOT set Search Scope to Place Records (_PLAC) and then you get the double sets of quotes. It is very important to follow my instructions EXACTLY to the letter.

Search and replace PLSS.png (35.38 KiB) Viewed 11296 times

[Ron Melby]

exactly like that except the _PLAC Fields

I hit for the print screen and come to paste, nothing happens, I go put it in a word doc, and cant upload the word doc, too big.

I get an error window:


File too large (Max 256Kb): Document.rtf

[tatewise]

Yes, well if you don't crucially restrict scope to _PLAC RECORDS it does not work correctly as you discovered.
I did say earlier that Place records are tricky to handle, so you MUST follow my instructions exactly and as reiterated in the plugins:help:search_and_replace:usage_examples#place_name_changes_in_fh_v6|> Place Name Changes in FH V6 guide. Did you look at that?
It says PrntScrn and Paste does not work, unless you go through the Paint tool.

Likewise, you MUST follow the advice I gave in info:forums#posting_topics|> Posting Topics to attach screenshots. Did you look at that?

You know how fussy software is at needing things exactly right.

I find it quite frustrating when I provide the perfect solution, and then you complain it does not work correctly, but it turns out that you did not actually follow the instructions properly despite the settings being highlighted in bold.

[Ron Melby]

It is of no matter, having ended up your way, the resultant table having "\[T......]\" in them, did not fix the problem

Valley "<hidden>", Marshall, MN, USA returns downtown Marshall, Lyon, MN, USA so having to adjust by hand, finding issues, and readjusting the different addresses, and places, it becomes an ordeal, Marshall, Lyon, MN being 500 kilometers from Valley, Marshall, MN I then have to drag pins on 8 to 10 areas on the shaky map
If I change the 0@_PLAC records only, that will be useful for less than 10 seconds, since I have 10s or hundreds in the file that do not match up. Eventually ending up with [2] records and

Now, this might be helpful when I ask for [ADDR]~{PLAC] which tables up both of the strings, where is the lat long coming from? ADDR or PLAC? because where I have an address, it will be a more precise location (since in most of the United States, they are GIS addresses) I would rather it favored the address, rather than place, but use place if no actual address. Less hand work for me.

If I change the 0@_PLAC records, that will be useful

[tatewise]

If you are saying that the Map Life Facts Plugin plots Valley "(T156NR39W)", Marshall, MN, USA in exactly the same location as Valley (T156NR39W), Marshall, MN, USA then sorry but you are just plain wrong! When I geocode them it shows:-

Valley "(T156NR39W)", Marshall, MN, USA is Lat 48.3185556 Long -95.6833511 near Grygla, Valley Township, Marshall, MN
Valley [[(T156NR39W)]], Marshall, MN, USA is exactly the same as above.

Valley (T156NR39W), Marshall, MN, USA is Lat 44.4484230 Long -95.7911916 at Marshall, Lyon, MN

If you use Valley ""(T156NR39W)"", Marshall, MN, USA with double quotes by mistake then it will plot at Marshall, Lyon, MN


The Google Maps Geocoder knows nothing about ADDR or PLAC and just sees all the geographic names combined.
It does its best to match up those names with geographic locations it knows about from modern maps.
If the names in your data are from way back, and so no longer exist, then it cannot find and plot them.
That is when you need to use a modern Substitute or manually adjust the plot.
USA ZIP codes might help give more accurate plots.
The Plugin itself has very little control over how the Google Maps Geocoder assigns its plots.

[Ron Melby]

I plot it with single quotes, never wasted my time double quotes it comes up marshall, lyon, mn

[tatewise]

I have no idea what you are doing wrong, but as you can see mine plots at Grygla, Valley Township, Marshall County, MN.
Does yours look like this?

MapLifeFactsValley.png (80.27 KiB) Viewed 11149 times

[Ron Melby]

I wiped out the database, and redid it from scratch, seems to work now.




My next issue is:
Which of these work the closest to the following algorthim?:

Do the lookup using address field where available, regardless of the place field, but use place field where there is no address field.
(5) looks like it might but, I have been surprised before.

1) ~ Place only option will plot every Place associated with any Fact.
2) Address ~ only option will plot every Address associated with any Fact.
3) Address ~ Place option will plot every Address & Place pair where BOTH appear in a Fact.
4) Address ~ [Place] option will plot every Address & Place pair even if the Place is blank.
5) [Address] ~ Place option will plot every Address & Place pair even if the Address is blank.
6) [Address] ~ [Place] option will plot every Address & Place pair even if either one is blank.

[tatewise]

Geocode Plot All Locations should have rebuilt the database without you wiping it.

It is difficult to answer to your question without knowing how you use Address and Place fields.
Usually, if there is an Address field entry, then there would be a Place field entry too.
But if you have Facts with an Address but no Place then the rules are different.

To include every circumstance where there is either an Address or a Place or both, then only 6) will work.
BUT when there are both, then both will be considered in the geocoding process, so Place is not disregarded, unless you enclose it in "string quotes".
If that same Place sometimes has an Address and sometimes does not, then you will two forms, one with "string quotes" paired with Addresses, and one without that has no Addresses.

To achieve the best geocoding, you will probably have to progressively work through your data over time adjusting some entries to match what the Google Maps geocoder prefers.

[Ron Melby]

in every case where I have an address, it is very correct, if I have an address where there is no place, its a mistake. I do not mind that where there is an address and place together

St. Petri Cemetery, 36200 300th Street NE, Grygla, MN, 56727, USA
, Valley "[T156NR39W S20]", Marshall, MN, USA

the address is much more granular. the place is more like describing the whitechapel murders (specifically, Annie Chapman, 29 Hanbury Street, Spitalfields took place in London. somewhere. My Chapmans came from England, and who knows if I have to mark that one?

where there is no address, the plac field is a distant second choice, but best I can do for now, from my first post on here, I have been working on place and address, heavily on address, and yes, my mistakes are still legion and will require further work. However, my addresses are only 2 of 840+ which do not geocode (both are multi rural address hits via google, and will look at them once I am near clean on everything, and the same of place, about 3 (2 in England and one US) which I will work on. Stone in Road, Tenterden being one of them. (from an 1881 census I believe, will have to dig in)

you remember where I was making the plugin that gave me:
USA.MN.Marshall St. Petri Cemetery, yadda yadda yadda, blah blah blah...I was using that to help sort out places where there is an address but no place quickly, I expect I will do a detailed Address with no place plugin unless there is one out there I dont know about already.

But knowing there are likely mistakes, yet, my best algorithm would be
1 address, haul place along
2 lack of address use place.

SEE St. Petri- Valley

[Ron Melby]

uncovered another issue for me...

, , Wabasha, MN, USA,
in my scheme this refers to wabasha county mn. it returns the location:

Wabasha, , Wabasha, MN, USA

is their a way to consistently treat this so it looks for county the commas schema is consistent throughout.

[tatewise]

Obviously neither FH nor Google Maps knows the meanings of your comma separated parts.
The only way to force Google Maps to plot Wabasha County is to use , , Wabasha County, MN, USA.
Either change the Place field, or in the Plugin set Substitute box to , , Wabasha County, MN, USA.

Since any Fact with an Address but no Place is a mistake, and will soon get corrected, it will make no difference whether you use 5) [Address] ~ Place or 6) [Address] ~ [Place].

You don't need a Plugin to find those mistakes, as a simple Fact Query will do it.
Start with standard Query called All Facts and use Query Menu > Save As Custom Query then add Rows:
Exclude if %FACT.ADDR% is null
Exclude unless %FACT.PLAC>% is null

Regarding Stone in Road, Tenterden, please check the Census image (NOT the transcript).
I suspect it does not actually say Stone in Road and just says Stone in Tenterden.
Stone is a popular name in England, so each one is identified as Stone in Ebony, Stone in Oxney, Stone in Tenterden, etc.