Jump to content


Photo

Merging Place Details ..


  • Please log in to reply
30 replies to this topic

#1 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 142 posts

Posted 08 November 2020 - 01:05 PM

I have a Place Details merge question. I have a cemetery that's been referred to as "cemetery name, state", "cemetery name, county, state", and "cemetery name, city, county, state". As I've been cleaning up places fairly aggressively I have these merged down to three entries, that reference a hundred or so each. (actually it was part of merging process that I discovered this issue). Is there a normal RootsMagic (i.e non-SQL) way to merge these three into one? I'm sure I have numerous situations similar to this.



#2 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 360 posts

Posted 08 November 2020 - 05:17 PM

If I correctly understand what you need, the answer is yes. You can do it from Lists/Place List. You should be able to find all  three versions. Choose the one that's closest to what you finally hope for,  highlight it, and merge the other two into it. Then edit the result.

 

I would separate the cemetery name into "place details," but I believe there are several members of this list who don't care for the place details feature. You may hear from them as this post is read more widely. I don't recollect the details of the discussion.



#3 John_of_Ross_County

John_of_Ross_County

    Advanced Member

  • Members
  • PipPipPip
  • 699 posts

Posted 08 November 2020 - 06:37 PM

Make certain that you do a backup before each merge.  Just in case!!



#4 John_of_Ross_County

John_of_Ross_County

    Advanced Member

  • Members
  • PipPipPip
  • 699 posts

Posted 08 November 2020 - 06:42 PM

Don't Do What I Did with Place Details

 

Take a look at my posting with the title above dated 11-JAN-2017.  Also followup postings.



#5 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3557 posts

Posted 08 November 2020 - 07:51 PM

Fourth bullet point on the link below from a 2012 posting, sadly never been fulfilled.

 

Place Details Management & Reporting

 

I do this using SQL.


Keeping ones customers and their important views at a distance is never a good approach

 

User of Family Historian 7.0.3, Rootsmagic 7.6.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#6 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 09 November 2020 - 08:08 AM

I have a Place Details merge question. I have a cemetery that's been referred to as "cemetery name, state", "cemetery name, county, state", and "cemetery name, city, county, state". As I've been cleaning up places fairly aggressively I have these merged down to three entries, that reference a hundred or so each. (actually it was part of merging process that I discovered this issue). Is there a normal RootsMagic (i.e non-SQL) way to merge these three into one? I'm sure I have numerous situations similar to this.

 

The same question just came up on RM's Facebook group. I can't remember if you posted the question there or if it was somebody else. In any case my answer is the same. I have to ask if you are entering the cemetery name as a part of the Place field or if you are entering the cemetery name as a part of the Place Details field. It makes a huge difference in solving the problem.

If you are entering the cemetery name as a part of the Place field, then the solution is simple. Just pick your preferred way of entering the data, go to that preferred way in the Place List, and merge the preferred with all the non-preferred ways. It should just take a couple of minutes, no muss and no fuss.

But if you are entering the cemetery name as a part of the Place Details field, you will have a real mess on your hands. I can't see a good solution other than a lot of tedious manual changes. For example, suppose you wanted to change "cemetery name, state" to "cemetery name, county, state" and suppose the cemetery name was in the Place Details Field. This means that you need to change "state" to "county, state" but only for the cases where there is an associated Place Details that's specific to your cemetery. Note in particular that you CANNOT simply merge "county, state" with "state" in the RM user interface because it will be unconditional - merging "county, state" with "state" in all cases, whether there is a Place Details field for your cemetery associated with your "state" or not.

This could be done with SQLite. The way I'm suggesting to do it, you would use SQLite to change "state" to "county, state" if and only if "state" had a Place Details field for your cemetery of interest. SQLite can handle the conditional nature of the needed change. I do realize that you might want to end up with the "cemetery name, city, county, state" form of the place name, and that's fine. That doesn't change the basic problem nor the basic SQLite solution. But there simply is not an automated solution from within the RM user interface because merging Place fields is unconditional in the RM user interface.

 

Jerry



#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 09 November 2020 - 08:19 AM

I was an early and eager adopter of RM's Place Details feature when it first came out. I spent a lot of time splitting all my Place fields into Place + Place Details where it made sense to do so, such as cemetery names, hospital names, etc. - anything beyond city, county, state. But somewhere along the way it dawned on me that RM's Place Details are usually lost when my RM data is transferred to most other genealogy software. I therefore have regretted my decision to adopt RM's Place Details feature ever since, and I have a long term project to put all my Place Details data back into the main Place field. I have chosen to do the project manually instead of with SQLite because I want to review very carefully each change I am making instead of doing a bulk change without review.

 

There have been many unfulfilled wishes for improvements in the way RM handles Place Details. But I don't think the problem of merging things like "cemetery name, state" and "cemetery name, county, state" when the cemetery name is in the Place Details field has been discussed before. This problem needs to be addressed in the context of improvements that are needed in the processing of Place Details.

 

Jerry



#8 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 156 posts

Posted 04 December 2020 - 09:41 AM

In my opinion, each location could be cited the same way sources and lineage are linked.

 

1 DEAT

2 PLAC @P12345@

 

0 @P12345@ PLAC

1 CHUR First Baptist Church

2 CITY Falls Church

3 STAT Virginia

4 CTRY United States of America

1 NOTE Text note about the location, such as its history.

 

If I am the first one to think of this I will be proud.



#9 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 346 posts

Posted 04 December 2020 - 09:49 AM

Does RM7 generate GEDCOM with PLAC as a record type?

 

This is almost like the GEDCOM 5.5EL proposal from a German genealogy group.  They use a _LOC record and in your case you would use a _PLAC tag since all non-standard GEDCOM tags should begin with a “_”.

 

http://wiki-en.genea...et/Gedcom_5.5EL

 

 

Their proposal is much more robust, allowing for multiple names that can be associated with time and country changes. It also includes geocoding and some other concepts.



#10 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3557 posts

Posted 04 December 2020 - 10:42 AM

But somewhere along the way it dawned on me that RM's Place Details are usually lost when my RM data is transferred to most other genealogy software. I therefore have regretted my decision to adopt RM's Place Details feature ever since, and I have a long term project to put all my Place Details data back into the main Place field.

 

Personally I never balance the ineptitude of other programs as a reason to thwart progress in the way I record and store data and I can confirm this RM Place Detail data is preserved in Family Historian as are Witness Events referred to as Shared Events in Rootsmagic.

 

Again, personally, I believe the exclusion of superfluous data from the primary Place field greatly adds to the possibility of harvesting matches both online and with other researchers, such "details" and the different personal preference of recording such site details can only hinder matches, that fact cannot be argued. Within Rootsmagic it also makes it possible to both Report and Map those community events within the geography of the primary Place. These finer Place Details can easily be discussed once multiple researchers have made contact and each researcher remains free to preserve their own personal preferences of how they are recorded in their database. I very much welcome that RM Treeshare allows users to deselect the upload of the Place Details component making the location field closer to some semblance of a standard and more readily understood by online services.

 

There have been many unfulfilled wishes for improvements in the way RM handles Place Details. But I don't think the problem of merging things like "cemetery name, state" and "cemetery name, county, state" when the cemetery name is in the Place Details field has been discussed before. This problem needs to be addressed in the context of improvements that are needed in the processing of Place Details.

 

I agree that management of Place Details does require further development efforts and careful consideration

.


Keeping ones customers and their important views at a distance is never a good approach

 

User of Family Historian 7.0.3, Rootsmagic 7.6.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#11 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 346 posts

Posted 04 December 2020 - 02:47 PM

Vyger said: 

 

 

Personally I never balance the ineptitude of other programs as a reason to thwart progress in the way I record and store data and I can confirm this RM Place Detail data is preserved in Family Historian as are Witness Events referred to as Shared Events in Rootsmagic.

The problem is NOT ineptitude of the programs it is the misunderstanding of how to use the Place Field with some software companies.  I always enter additional place information such as cemetery name in the place field.  I even, when I have it, grave location information in the Place field as well.  What I can’t understand is the real value of “place detail” other than for cemetery or street address information!



#12 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3557 posts

Posted 04 December 2020 - 03:02 PM

Vyger said: 

The problem is NOT ineptitude of the programs it is the misunderstanding of how to use the Place Field with some software companies.  I always enter additional place information such as cemetery name in the place field.  I even, when I have it, grave location information in the Place field as well.  What I can’t understand is the real value of “place detail” other than for cemetery or street address information!

 

It's the old when is a Site a Place argument, I just prefer my Places to be internationally recognized. If I ask "where did the person live?", you will reply with a Town, City or County, you will not naturally rime off a street address and zip code unless I enquire further. You might have someone down as being born as Belfast, Ireland and if I didn't use Place Details I might have them down as Mervue Street, Belfast, Ireland those strings do not match and rely on AI of apps to associate them.

 

From a matching point of view the Belfast, Ireland connection is sufficient to research further, the prefixing of a street address or site in never ending user preferred formats only convolutes the location information, but then everyone is free to enter whatever they wish in the location information fields.


Keeping ones customers and their important views at a distance is never a good approach

 

User of Family Historian 7.0.3, Rootsmagic 7.6.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#13 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 346 posts

Posted 04 December 2020 - 04:03 PM

My comment is not about how you enter the data, but that you indicated that it was “ineptitude” of software that they did not support  “Place Detail”.  I respect however your desire to keep place information simple.

 

On the other hand....  

 

Because of global mapping on most software and in particular “Open Street” a free app, I don’t care if people know about Mervue Street in Belfast or not, they can easily find the location themselves via this or other avenues. Because I use the place field for all location information I can enter it in “Open Street” and map directly to that software and actual see just how close relatives are to one another or how far (or short) they travel in their lifetime.  In some cases I’ve found other relatives living in the same apartment building, just next door or around the corner by mapping the exact location.  My online viewers can actually visualize the relationship  of two farms where an eventually married couple came from, which has led to conversations about how they may have met if a mountain existed between them and little or no roads existed in rural Norway.



#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 04 December 2020 - 09:04 PM

 

It's the old when is a Site a Place argument, I just prefer my Places to be internationally recognized. 

Maybe you don't need street addresses in some cases, or maybe in any cases. But one Place Detail type of item that is absolutely critical is cemetery names (or the fact that somebody was buried on the family farm).. In my opinion, not including cemetery names in place name standards is just a travesty. It may not be quite as critical, but I also record places where people were born or died such as the names of hospitals - but not the actual address of the hospital.

Jerry



#15 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3557 posts

Posted 05 December 2020 - 07:52 AM

My comment is not about how you enter the data, but that you indicated that it was “ineptitude” of software that they did not support  “Place Detail”.  I respect however your desire to keep place information simple.

 

On the other hand....  

 

Because of global mapping on most software and in particular “Open Street” a free app, I don’t care if people know about Mervue Street in Belfast or not, they can easily find the location themselves via this or other avenues. Because I use the place field for all location information I can enter it in “Open Street” and map directly to that software and actual see just how close relatives are to one another or how far (or short) they travel in their lifetime.  In some cases I’ve found other relatives living in the same apartment building, just next door or around the corner by mapping the exact location.  My online viewers can actually visualize the relationship  of two farms where an eventually married couple came from, which has led to conversations about how they may have met if a mountain existed between them and little or no roads existed in rural Norway.

 

We all do research differently, we all have our own ways which work for each of us, in my case I do several one name studies so have many unconnected trees so I find the ability to visualize geographical groupings very beneficial, that would not be of such importance to other users and I fully understand that. So for me it's not just a simple matter of plugging several unassociated entries into a mapping provider to see if they are close, as you will see on the image below I can visualize these communities very well within Rootsmagic by using Place Details as they were intended. Apart from the database scalability benefits I can easily visualize these events and families as well as entering Churches and Cemeteries with some history notes and media for future benefit, it's a way I find very beneficial as I extensively research Parishes and localities but I fully understand it would not be of equal benefit to all, especially single tree researchers.

 

So using the Mervue Street, Belfast example I can also easily visualize on one view the geographic clues of cousins and married family members in geographic clusters aiding my further research into these families (maiden surnames are generally dropped on marriage in UK&Ireland)

 

Maybe you don't need street addresses in some cases, or maybe in any cases. But one Place Detail type of item that is absolutely critical is cemetery names (or the fact that somebody was buried on the family farm).. In my opinion, not including cemetery names in place name standards is just a travesty. It may not be quite as critical, but I also record places where people were born or died such as the names of hospitals - but not the actual address of the hospital.

Jerry

 

Firstly I was also an early adopter and remain frustrated by many Place Detail deficiencies but I suppose I have kept the faith things will improve and that faith is wearing a little thin. FH maintains these Place Details as Address associated with the Event but the current version makes no further use of the site Geocoding, Notes or Media but the additional information is preserved in the database so FH7 could be a permanent turning point for me and my research.

 

Regardless, I am not attempting to teach Grannie how to suck eggs, I am simply defending the usefulness I have found in using Place Details in my own work whilst describing some of the benefits to newer users and members. We all realize migrants usually went to a location where a family member had migrated before or at least where an ethnic community already existed so the Mapping visualization and geographic reporting is very beneficial to my research. We also know how rural farm locations do not fale well into the requirements of Gazetteer and large City geocoding, there are several large and historically established market town in Ireland which simply do not exist in Gazetteer. On a smaller scale many people and families moved to Belfast in search of work with no clues of where the family originated. Sadly the earliest comprehensive family grouping source in Ireland is the 1901 Census Return with the only requirement being to note your County or City of birth or Country if outside Ireland, this presents its own particular set of research challenges. Whilst I am lucky to deal with relatively uncommon Surnames I have few distinctive occupations like Astronaut and there are one heck of a lot of farmers and labourers out there so geographic proximity clues are heavily weighted in my research.

 

belfast-place-details.png


Keeping ones customers and their important views at a distance is never a good approach

 

User of Family Historian 7.0.3, Rootsmagic 7.6.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#16 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 156 posts

Posted 05 December 2020 - 09:46 AM

RootsMagic could export GEDCOM files that put the place details in a NOTE which was the way people were once taught.



#17 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 346 posts

Posted 05 December 2020 - 11:09 AM

RootsMagic could export GEDCOM files that put the place details in a NOTE which was the way people were once taught.

Yes, GEDCOM does support a NOTE field as part of PLACE_STRUCTURE so that would be the appropriate place for the GEDCOM export.

PLACE_STRUCTURE:=

n PLAC <PLACE_NAME>
 +1 FORM <PLACE_HIERARCHY>
 +1 FONE <PLACE_PHONETIC_VARIATION>
      +2 TYPE <PHONETIC_TYPE>
 +1 ROMN <PLACE_ROMANIZED_VARIATION>
      +2 TYPE <ROMANIZED_TYPE>
 +1 MAP
     +2 LATI <PLACE_LATITUDE>
     +2 LONG <PLACE_LONGITUDE>
 +1 <<NOTE_STRUCTURE>>


#18 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 05 December 2020 - 06:25 PM

 

Yes, GEDCOM does support a NOTE field as part of PLACE_STRUCTURE so that would be the appropriate place for the GEDCOM export.

PLACE_STRUCTURE:=

n PLAC <PLACE_NAME>
 +1 FORM <PLACE_HIERARCHY>
 +1 FONE <PLACE_PHONETIC_VARIATION>
      +2 TYPE <PHONETIC_TYPE>
 +1 ROMN <PLACE_ROMANIZED_VARIATION>
      +2 TYPE <ROMANIZED_TYPE>
 +1 MAP
     +2 LATI <PLACE_LATITUDE>
     +2 LONG <PLACE_LONGITUDE>
 +1 <<NOTE_STRUCTURE>>

 

 

How would the following real information fit into this structure?

A couple was married 4 May 1797 at the Rehoboth Church in Greenbrier County, Virginia. The GPS coordinates of the church are 37.58968,-80.50632. Since then, Greenbrier County has been split into two counties, and the church is now in Monroe County. And since then, Virginia has been split into two states and both Greenbrier County and Monroe County are now in West Virginia. The church is still there and its GPS coordinates are still 37.58968,-80.50632.

Also, I have hundreds of burials in my database where I have visited the gravesite, recorded the GPS coordinates with a very accurate handheld GPS device, and entered the GPS data into RM along with a photo of the gravesite.

Therefore I need a structure that will record individual grave sites and their GPS coordinates within a cemetery within a city,county,state. I need for all this information to appear in RM's narrative reports and when I publish my data on the Web. And I need for this information not to be lost when my data is transferred to genealogy software outside of RM. So that's the challenge I'm laying down.

 

Jerry



#19 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 346 posts

Posted 06 December 2020 - 12:35 AM

Jerry,

Let me start with the very last question, you asked:

"And I need for this information not to be lost when my data is transferred to genealogy software outside of RM."

From my point of view this question has two answers, although neither is too good! 

1) If we are talking about pure GEDCOM The only way to not lose data is for RM to actually Create/Generate proper GEDCOM v5.5.1 AND the receiving program to actually read and understand proper GEDCOM v5.5.1.  As you know this will probably not happen in our lifetime.  It is possible that RM may Generate proper GEDCOM in the future, and it is possible that some receiving programs may also read proper GEDCOM, but there is a lot of moving parts in this area and I fear that it will not happen.
2) If we are talking about non-GEDCOM solutions, this may already be available to some degree, but this capability is beyond my understand.  I understand that some programs can read the open database of RM and import the data into their structure so that data lose is minimized but DB structures will be different. Again, I am not a major user of any other program at this time because I struggle with data transfer.

The next question I want to investigate is:

"I need a structure that will record individual grave sites and their GPS coordinates within a cemetery within a city,county,state."

If I look at the parameters you provided I can say that I have multiple example of exactly the same situations.  I have farms, graves, houses, that have resided in multiple countries, counties, Kommune, Fylke, that have had multiple names/spellings over time as well as at the exact same time.  I also have GPS coordinates for those exact spots recorded by either myself or one of my foreign or domestic Genealogy helpers. If I look at the current structure of GEDCOM v5.5.1 I can see the following constraints.  1) an event/attribute (aka fact) can have at most one PLAC tag saying that a fact can happen only in one place not multiple.  2) If you rule out using the FONE and ROMN tag which are used for Asian glifs, you are left with the following tags, PLAC, PLAC.FORM, MAP.LATI, MAP.LONG and NOTE.  

Your constraints indicate that you need to record the following:

1) GPS location
2) Current Name of the GPS location
3) Historical Name(s) of the GPS location and potentially the history.

Before I give my solution I must reveal that 1) my database is not RM 2) My database is in the process of change due to some additional non-GEDCOM enhancements recently incorporated into the code.

However, my most recent philosophy when using pure GEDCOM v5.5.1 would be:

The PLAC tag would hold the most current values for the GPS location.  This is so my readers/viewers have a sense of the modern location. The GPS location would include the actual grave, church,farm, or house address.  In the case of the your church site you can either enter the name of the place at the time of the event (shown here) or as I would with the modern name (Rehoboth, Monroe, West Virginia, USA) and explaining the history in the notes in some fashion as indicated below:

2 PLAC Rehoboth, Greenbrier, Virginia, USA
3 FORM Church, County, State, Country
2 MAP
3 LATI W80.506320
3 LONG N37.589680
2 NOTE @N999@
-or-
2 NOTE The church where this event occurred has not moved but been part of the several different counties and two different states with in the USA. The following additional information can be
3 CONC found on Wikipedia about the historical changes in Greenbrier County.
3 CONT
3 CONT Here is an excerpt from the Wikipedia page: https://en.wikipedia...,_West_Virginia
3 CONT
3 CONT During the secession crisis of 1861 Greenbrier citizens chose Samuel Price as their delegate to the Richmond convention. On April 17, 1861, the day Virginia's secession ordinance was
3 CONC passed he voted against it, but later changed his mind and signed the official document.[6] When the public vote on the secession ordinance was held on May 23, 1861, Greenbrier county
3 CONC voted 1,000 to 100 in favor of secession.[7] The Civil War came to the county in mid 1861, and several battles were fought in the area, including Lewisburg in May 1862 and White Sulphur 3 CONC Springs in August 1863. Both battles were Union victories. Greenbrier County became part of the new state of West Virginia, although it never participated in any of the votes held by the
3 CONC Restored Government in Wheeling. West Virginia contributed approximately 20,000 men to the Union and an equal amount to the Confederate army, with approximately 2,000 men from Greenbrier
3 CONC county joining the Confederate army.

All of this being said I will also indicate that the PLACE_STRUCTURE in GEDCOM v5.5.1 is not to my liking as it is incomplete in both data normalization, location and complete historical information.  I've been active in various committees over the years to augment the information that can be stored in this structure as well as to further normalize the data.

This brings me to the structure that has been proposed by the German Genealogy Group as GEDCOM v5.5EL as noted above.  This solution is not by any means perfect. It does however incorporate some concepts that I do see an important. 1) Provides a DATE_VALUE that can be used as a range of when the name was in use 2) Hierarchical Relationships, this way a place can reside within multiple other places while still retaining its location (GPS Location). 3) Multimedia links to photos of the place, or records about the place.

One thing it is missing is Polygonal location rather than geographical coordinates.  Places/Locations are not always a coordinate but a polygon surrounding the place (a city, a State, a cemetery).  Some of the data retained may be specific to German places and the Genealogy Groups in Germany and may not be Internationalized well or universal in their usage.  This model is however useful as a stating place for discussion.  

 



#20 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 06 December 2020 - 08:34 AM

One thing it is missing is Polygonal location rather than geographical coordinates.  Places/Locations are not always a coordinate but a polygon surrounding the place (a city, a State, a cemetery).  Some of the data retained may be specific to German places and the Genealogy Groups in Germany and may not be Internationalized well or universal in their usage.  This model is however useful as a stating place for discussion.  

I very much thank you for your most complete and thoughtful reply. And to tell you the truth, the limitations you pointed out are also limitations I see and they are most discouraging.

 

In effect, I'm already doing some but not all of what you suggest for the GEDCOM structure, except that I do it from within RM. For example, I do it within notes as your GEDCOM structure shows. In addition, I put GPS coordinates either in Notes or in RM's Description field, because RM doesn't support printing of GPS coordinates that are associated with the Place field. So I don't do anything myself in RM that creates any LATI and LONG tags in GEDCOM.

I didn't mention the need for Polygonal location because I thought that might be a bridge too far. But I do plat out a lot of old deeds in such a way that they can be displayed on a modern map with tools such as Google Maps and Google Earth. That means that not only do I have to plat out the old deeds in terms of their metes and bounds descriptions, I also have to work out the GPS coordinates for at least one corner. Such platting work is entirely outside of RM, and the best I can do is to provide URL's to such maps in RM. When I make Web pages from my RM data the URL's show up. I store the URL's as {private notes} in RM so they won't print, but I include the {private notes} when I make Web pages.

Another problem with GPS locations that I didn't mention is that even single point locations can be problematic when they really refer to a general geographic area instead of to a single point such as a grave site. For example, what if all I know is that someone was born in Canada and I want to show that on a map. Where does the pin with the GPS coordinates go on the map? In the case of the United States, you might place such a pin somewhere in the middle of Kansas, I suppose, but such a pin in Kanas is pretty meaningless if the event too place in 1790 and all you know is that it took place in the United States.

 

Jerry