Jump to content


Photo

Place names standard


  • Please log in to reply
70 replies to this topic

#21 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 203 posts

Posted 22 December 2016 - 10:35 AM

I love standards, but you have to know where your standards are coming from and who controls the standard and the data it represents.

 

Take a look at this effort by a genealogy group in Germany.  Their standards are far more reaching than the one used here.

 

http://gov.genealogy.net/

 

This has the capability of including Churches and exact places on any map.  It is rather European Centric and mostly filled by volunteers, but if adopted by all vendors has far more value than many other coding standards.

 

Also....  And please forgive me in advance for talking about GEDCOM when so many don't really care.

 

The PLAC tag includes the following construct:

 

n PLAC Thornton's Ferry, Merrimack, New Hampshire, United States
n+1 FORM Village, City, State, Country

n+1 MAP

n+2 LATI -71.493611

n+2 LONG 42.866389

 

Any mapping software could take this Longitude and Latitude and create a point.  However I have yet to see commercial software include this "standard" in their database or GEDCOM Import/Export. 

 

These are the reasons that I harp on about GEDCOM, but as I've said:  If the software vendors and the users of the software don't know or care about these things then, I'M OUT because I have no real value in any discussion.

 

No amount of commas can fix this issue in England:

 

The hamlet of Ashton exists in two places in Northamptonshire, England   Nothing other than Latitude and Longitude designations will tell you where it is on a map.

 

 

 



#22 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 255 posts

Posted 22 December 2016 - 11:04 AM

The advent of GedSite, John Cardinal's new program for making web sites from GEDCOM files may make the latter more central to the genealogy enterprise. Genealogy software developers may be less interested, as has been pointed out in this thread.

 

That said, I'm very skeptical about the standardization of places by providing "slots" for their elements in database programs or, indeed, in GEDCOMs. The diversity of reality will defeat standardization every time: there's always an exception — or dozens. Many examples appear in the posts above.

 

If the genealogist but knew places exactly, then latitude and longitude would identify any place — but who would want to read the report? Only text written by a human being will permit the conveyance of the diversity of "place." The best genealogy programs offer the most powerful and flexible report engines as well as fall back to word processing formats if necessary.

 

 

Robert



#23 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 203 posts

Posted 22 December 2016 - 11:42 AM

Robert,

You said: "I'm very skeptical about the standardization of places by providing "slots" for their elements in database programs or, indeed, in GEDCOMs."

 

I agree 100% with you, to the point that "slots" in RM or FTM or other non-GEDCOM centric programs is not the right way to go.  Rather they should have a dedicated database table or record type that support a robust Location architecture.

 

I could write a whole paper about place/location repositories as it relates to genealogy.  But it would bore 99.9% of readers here and probably get be kicked off this site.

However, place location requires some of the following, Name(s), Divisions participating in, Subdivisions, GeoLocation Polygon, Short Description, History, GEDCOM Code/Hierarchy. 

 

The "Name(s)" part would actually be a list of all names and spellings. 

GeoLocation would not be a point but a polygon that generates an area and each polygon would have dates from/to to show when in history it was an active location.  This is important for the Thorton's Ferry and country or regional changes to locations.

 

GEDCOM fails in this concept completely!

 

Reports would not display a GEDCOM like comma delimited string but a "printable name" based on the place/location table desribed above.

 

Again I'm sorry that I have just bored everyone but Robert pushed me to it!  :)



#24 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 22 December 2016 - 11:53 AM

These are always interesting discussions and really always boil down to 3 common points.

 

1. Identifying like events through genealogical exchange and the written place name being of some standard.

 

2. Knowing the point on earth within as small a margin of error as possible regardless of administrative district changes over time.

 

3. Each users preference for how things look in reports.

 

I believe all 3 are covered within RM with Notes and Media which can be added for extra quality. The questions circulate around how each genealogy program make use of each component, help researchers make better use of proximity of GPS, share standardized place names and help drive users towards better quality place geocoding and finally allow more flexibility in report output formats to please all.

 

I believe this recent thread was a good example - http://forums.rootsm...ng-place-names/


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#25 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 203 posts

Posted 22 December 2016 - 12:34 PM

Yes I found the question and issue on that one interesting.

 

Since the location of a place can physically move (example: a church could change location but not change name) and a location(point on a map) could change its name.  Street names change, city, country, region names change, etc.... 

 

This relationship becomes a many to many setup.  GeoLocation (map point or polygon) <M-M> Location Name.   (I.E. A GeoLocation can have many names and a name can have many locations.)

 

Because nothing I have seen in Genealogy supports this concept I tend to record the modern name for GeoLocation purposes so that Google map can find most everything.  Then use Notes to support alternate names and location GPS.

 

I always record the exact place down to the street address or cemetery plot number as "the place"  just like I would include Thomson's Ferry.  Because I also have the exact GPS for Thompson's Ferry or can get close on a grave plot using available data.  I have not issues with being detailed with my "places".  If I record a cemetery plot and only know the cemetery location or the city the cemetery is found in, no problem.  I'm close enough for today and I can always fix it later because every place has a GPS location associated with it AND I can control that GPS location, I'm not beholding to a rigid list of places/GPS. 

 

This discussion continues.



#26 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 22 December 2016 - 02:07 PM

This discussion continues.

 

Don't get me wrong KFN, I am very PRO geocoding, I use Place Details and I see them as being, mostly, important detail to me and eventually (hopefully) enhancing reports and publishings.

 

I detest duplication especially where it can be avoided, if anyone was to send me a gedcom (and after 25 years I have received many) the first clean-up is removing the personal styles of recording Places. For example I record a street address as Main Street (#nnn) to group them together, really I should be able to rely on the geocoding to group these within a definable proximity.

 

In Ireland there are 60K+ Townlands and they are the most reliable land division definitions for the last 300+ years, they all belong to Parishes many of which have changed over time, each Parish is part of a Barony, which is part of a Province and part of Ireland. This information is not reliably mapped and I have broken with genealogy standards to build and maintain my own dataset of this important information. However I record the Parish as the Place and the townlands, Churches and towns etc. as Place Details within those Parishes, so far it works well for me.

 

Knowing the Parish, I have my own little Gazetteer within Rootsmagic which helps greatly with badly transcribed records as when I select the Parish I have a list of the Townlands and Churches within that Parish within Place Details as reference. 


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#27 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 203 posts

Posted 22 December 2016 - 02:24 PM

Can't argue with you about varying and inconstant place information found in most data be it GEDCOM or primary sources.

 

This is why I never advocate people just merging another person's GEDCOM into their own but rather re entering all of the data AND as they enter it verifying that the sources are good and defined correctly, adjusting place names,  making sure that person names are consistent (I don't use AKA) and I do use multiple NAME tags with Name Types (not supported in FMT or RM).  I must also adjust DATE ranges because some GEDCOM software does not know the difference between FROM/TO and Between.  I also must remove custom "Facts and Events and generate proper FACT/EVEN tags with TYPE and remove "Description" in tags where none is allowed. 

 

But this is all too geeky and not what this thread is all about.    



#28 John_of_Ross_County

John_of_Ross_County

    Advanced Member

  • Members
  • PipPipPip
  • 645 posts

Posted 22 December 2016 - 03:03 PM

State boundaries change.  One of the biggest examples is the split of West Virginia from Virginia.  I have found data for people born in West Virginia in the 1840's.  It makes me doubt the research.

 

With this in view, it would be nice to have some scheme that is a linked list of the present placename back to previous names.

 

County boundaries change.  The typical change in Ohio is the split of a township from an older county to form a new county composed of townships robbed from other adjacent counties.



#29 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1466 posts

Posted 22 December 2016 - 07:20 PM

 

With this in view, it would be nice to have some scheme that is a linked list of the present placename back to previous names.

 

I think this is the intent of the County Check feature. I have County Check turned off, and don't use it, because I prefer to use the place level designations (parish, township, county, etc) and County Check does not. If the use of those designations could be toggled on/off by a user selection (perhaps under Tools - Program Options) then I would seriously re-consider using County Check.



#30 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6131 posts

Posted 22 December 2016 - 10:15 PM

KFN, a short course on RootsMagic may help you to understand the constraints RM users work with and around and the implications of what you advocate (I think you do appreciate the wrenching around of the entire application that would be required to support the FORM construct).

 

RootsMagic exports the following for an event in a place (high level such as a municipality) with a "place detail" (street and number, name of institution, cemetery plot, ...):

1 DEAT
2 _PRIM Y
2 DATE 10 DEC 1859
2 PLAC Glasgow, Scotland
2 ADDR 90 Cumberland Street, Hutchesontown
3 MAP
4 LATI N55.8482750
4 LONG W4.2578917
...
...
0 _PLAC Glasgow, Scotland
1 MAP
2 LATI N55.8575667
2 LONG W4.2529361 

In RM parlance, "place" is PLAC and amplified with Lat/Long and Note in the master record output to _PLAC; "place detail" is output to ADDR subsidiary to PLAC and while it has a master record in the database (just another record in the PlaceTable), there is no corresponding master place detail GEDCOM tag.

 

A master place has three possible names: Name, Abbreviation and Standard Name. The latter is automatically populated when a place is automatically geo-coded. The user can override that name and input anything into all three names. However, only Name is exported and only Name and Abbreviation are accessible for narrative reporting. In the example above, the Standardized Name from geo-coding is "Glasgow, Lanarkshire, Scotland, United Kingdom" but I chose to use the simpler "Glasgow, Scotland" for the accessible Place name and Glasgow as the Abbreviation. The geo-coded place detail is in the ADDR sub-tag of PLAC.

 

Typically, the place name is comma separated from low to high levels into 4 levels but it can be 1 to many. Thus someone could put the place detail value into the place field instead - 6 levels in this example. Everyone wrestles with having the country name included when it is easily inferred from the lower levels. The RootsMagic County Check tool insists on it and there is no way to suppress it from reports (with maybe one not easy exception). Place indexes in reports are built from the Place Name, typically in reverse order to the way it is stored,

 

RootsMagic has no mechanism to relate each level to a geopolitical type and I suspect to do so would require breaking up each name field into multiple fields or, at least, a constant number of parsable strings which is what I think TMG did. I recall from scratching its surface that it supported user defined place templates to define what each level was and presented an input form with labels based on the chosen template. Thus the same database field could be used for a variety of geo-political structures. I don't know if TMG supported the FORM tag but, in principle, it could have. RootsMagic would require major programming changes if not also structural modifications to be able to support the FORM tag as you explain it and maintain the interfaces it has or is developing with FamilySearch and Ancestry.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#31 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 203 posts

Posted 23 December 2016 - 10:21 AM

Tom,

 

In looking at the GEDCOM created by RM for an event, specifically looking at the PLAC, ADDR and MAP tag these would be somewhat invalid GEDCOM.  PLEASE NOTE:   The ADDR tag is not a sub-tag of PLAC as noted in your commentary.

 

The place_structure for v5.5.1 is as follows.

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

 

The Address_Structure for v5.5.1 is as follows:

ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE>
n+1 CONT <ADDRESS_LINE>
n+1 ADR1 <ADDRESS_LINE1>
n+1 ADR2 <ADDRESS_LINE2>
n+1 ADR3 <ADDRESS_LINE3>
n+1 CITY <ADDRESS_CITY>
n+1 STAE <ADDRESS_STATE>
n+1 POST <ADDRESS_POSTAL_CODE>
n+1 CTRY <ADDRESS_COUNTRY>
n PHON <PHONE_NUMBER>
n EMAIL <ADDRESS_EMAIL>
n FAX <ADDRESS_FAX>
n WWW <ADDRESS_WEB_PAGE>

 

With the following Notes (the highlight is mine):

 

The address structure should be formed as it would appear on a mailing label using the ADDR and

the CONT lines to form the address structure. The ADDR and CONT lines are required for any

address. The additional subordinate address tags such as STAE and CTRY are provided to be used

by systems that have structured their addresses for indexing and sorting. For backward compatibility

these lines are not to be used in lieu of the required ADDR.and CONT line structure.

 

So based on the standard the following would be wrong because the ADDR tag does not have a sub-tag of MAP and that the single line ADDR should be expanded to include the required CONT for the city, state, and zip:

1 DEAT

2 _PRIM Y

2 DATE 10 DEC 1859

2 PLAC Glasgow, Scotland

2 ADDR 90 Cumberland Street, Hutchesontown

3 MAP

4 LATI N55.8482750

4 LONG W4.2578917

 

And should be formatted as:

1 DEAT

2 _PRIM Y

2 DATE 10 DEC 1859

2 PLAC Glasgow, Scotland

3 MAP

4 LATI N55.8482750

4 LONG W4.2578917

2 ADDR 90 Cumberland Street, Hutchesontown

3 CONT Glasgow, Scotland 

 

 

Tom said:

RootsMagic has no mechanism to relate each level to a geopolitical type and I suspect to do so would require breaking up each name field into multiple fields or, at least, a constant number of parsable strings

Yes I completely understand agree with this approach, since it is what my program does to develop place hierarchy.  Places therefore are not a single record but a linked list of hierarchy with GPS as each level. 

 

Finally...  One of the main issues I do have and this is the battle that I will always loose is Ancestry, the gorilla of non-compliant, do it my way, strong arm companies that have crippled the GEDCOM standard and will most likely prevent the much needed changes in GEDCOM and the future of inter-application standardization that I and most of us should be striving for.  



#32 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6131 posts

Posted 23 December 2016 - 10:50 AM

Returning to the start of this discussion, the issue raised is around the suppression of County and other jurisdictional designations in RootsMagic County Check, Gazetteer, FamilySearch et al. It's been a not-so-merry go-round for RM users struggling with trying to do the "right thing" and make decently readable narrative reports while being hounded by County Check and troubled by the losses or changes when interfacing with outside systems. This discussion got me thinking about possible workarounds and I came up with this. It's not pretty but it makes both CountyCheck and geo-coding happy and can produce better narratives.

 

It's based on how the three names for a place function and what is currently available in the RM sentence template language:

  • Abbreviated place name is the only one over which the user has both exclusive control and access by the sentence template
  • Standardized place name is modifiable by geo-coding and is inaccessible for narratives
  • Place name is tested and modifiable by CountyCheck for historical correctness of county, state/prov, country irrespective of the lower level place

So what if we use Abbreviated in a way that is different from what was intended? Have a look at this:

1.  Standardized Name: Whitby, Ontario Canada
Place Name [Place:plain]: Whitby Twp., Ontario, Canada, British North America
[Place:original:plain]: Whitby Twp., Ontario, Canada, British North America
[Place:Abbrev:plain]: Ontario Co., Canada West
[Place:first:plain]: Whitby Twp.
[Place:last:plain]: British North America
[Place:Abbrev:first:plain]: Ontario Co.
[Place:Abbrev:last:plain]: Canada West
Composite:
[Place:first:plain], [Place:Abbrev:first:plain], [Place:Abbrev:last:plain], [Place:last:plain]
Whitby Twp., Ontario Co., Canada West, British North America
OR
[Place:first:plain], [Place:Abbrev:plain],  [Place:last:plain]
Whitby Twp., Ontario Co., Canada West, British North America
OR NO COUNTRY
[Place:first:plain], [Place:Abbrev:plain]
Whitby Twp., Ontario Co., Canada West
OR NO COUNTY NOR COUNTRY
[Place:first:plain], [Place:Abbrev:last:plain]
Whitby Twp., Canada West


Place Detail [PlaceDetails:plain]: 300 Centre St. S., Village Centre
[PlaceDetails:first:plain]: 300 Centre St. S.
[PlaceDetails:last:plain]: Village Centre


Orrilla Fitchett1–2 lived at 300 Centre St. S., Village Centre in Whitby Twp. in 1866, following the death of her husband.

I've used Abbreviation to store the expanded name of the county and the province. What is in the Place name is what came from CountyCheck which cares not that I put Twp. into the name of the municipality. With this 4-level Place and the 2 mid-levels in Abbrev, the :first and :last modifiers can parse the 4 levels and various combinations are then possible. Two levels of Place Details can also be parsed (first and last) - one could be street name and no., the other the name of the building.

 

There are a lot of hoops to go through and variations that could be tried. I've previously requested an enhancement of the sentence template modifiers that could parse out more levels, e.g., :second, :third or maybe :L1, :L2, ... where 1 is the rightmost or country level.

 

A downside is that RM does not transfer the Abbrev and Standard values through GEDCOM or drag'n'drop nor custom sentences for builtin events and roles.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#33 tconrad

tconrad

    Member

  • Members
  • PipPip
  • 24 posts

Posted 26 December 2016 - 10:40 AM

Great topic!   I have been very frustrated with the standard that relies on only commas.   In too many cases, my brain processes the location where a location like "Jefferson" can refer to a county, township or city within a small geographic area.  When people moved around, I have to constantly stare and decode which one the record refers to.

 

I think the ultimate goal should be clarity.   A standard that makes locations uniform in order to aid computer matching, but hinders the ability to effectively communicate the location is missing the mark.   Computers can handle these tasks and not shift the burden to dumb humans.

 

My thought - there should be certain key words that computer programs should strip out when doing location comparisons.  If someone wants to add "Township" or "Twp", or "County" or " Co ", then just let people add these clarifiers when entering their data but programs strip them out and use the comma positions only for matching.   If someone likes be as terse as possible, fine.  If someone wants the long versions, fine.  And if someone wants to use abbreviations (since space on a screen is sometimes a premium), that's OK too.   In 2016, computer programs can strip out what someone called "superfluous" text without difficulty.   Just put things in proper order.

 

TomH - were you suggesting that these place abbreviations are stored and managed, or just stripped out like I'm suggesting?



#34 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6131 posts

Posted 26 December 2016 - 03:11 PM

TomH - were you suggesting that these place abbreviations are stored and managed, or just stripped out like I'm suggesting?

I don't understand your question. RootsMagic already has the three place name fields and the variables and modifiers for retrieval of values from two by the sentence template. All I have done is to demonstrate an unorthodox way of using them to some advantage.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#35 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6131 posts

Posted 26 December 2016 - 04:30 PM

The ADDR tag is not a sub-tag of PLAC as noted in your commentary.

My error; I should have said something like "The GEDCOM ADDR tag is not a subtag of PLAC but the RM database structure does have the Place Detail subsidiary to Place". The fact that ADDR appears in the same GEDCOM block as PLAC implies a relationship between them. So, while it may be invalid GEDCOM, I get why it is done. It eliminates the CONT Glasgow, Scotland line under ADDR which merely repeats the PLAC Glasgow, Scotland line so adding no new information. And the "master" custom _PLAC tag "normalises" the data about "Glasgow, Scotland" (Lat, Long, note, media link) so that it is not issued with every event that uses this PLAC. 

 

It is interesting to note that such "normalisation"of GEDCOM was not done for Place Details (ADDR). I guess the rationale is that there would be many fewer uses of a Place Detail than of the Place to which it belongs. Within the RM database structure, the Place Details are normalised, i.e., 1 unique record for each unique place detail.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#36 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3348 posts

Posted 26 December 2016 - 05:43 PM

I repeat again my belief the Standardized Place Name should be the shared Place information online and by gedcom where it is populated, County Check suggestions should populate this field rather than overwriting the users Place entry when selected, does anyone offer any objections to this model?

 

As a development direction and following on from the above post from TomH, perhaps a 4th Place field like Historical Place Name should be catered for which could detail Parish or other information describing that Place.


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#37 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts

Posted 26 December 2016 - 09:17 PM

One of the major issues with the way many software programs implement "Place" is that they don't provide for a "Format" contruct as outlined in GEDCOM.

 

Here is an example from the original question"

Thornton's Ferry, Merrimack, New Hampshire, United States

 

In GEDCOM I would enter the following:

n PLAC Thornton's Ferry, Merrimack, New Hampshire, United States
n+1 FORM Village, City, State, Country

 

This construct tell the system and anyone reading the document to look for a place called Thornton's Ferry (a village within the city of) Merrimack (in the state of) New Hampshire (within the country of) United States.

 

This "FORM" tag can be set globally so that all PLAC tags without a subtag of FORM uses the standard default.  Therefore in many cases only a few outlying (non-standard) places would need a FORM tag to describe the data.  So most of your entries will not need a county if you don't want to record it, but for a few of the places that have cities of the same name in different counties then add a FORM tag and tell the system that the county is included in the place.

 

This is actually the way I do it, but since almost no software programs that I have come accross use the FORM tag I would be forced to use the example above with the city and state in the names.

 

Actually, it is the Town of Merrimack and not a city. In this regard, the hierarchy of areas is equal. Towns in New Hampshire do not overlap each other nor do they overlap cities. However, consider

 

Towson, Baltimore, Maryland, United States

 

which is the city of Towson in Baltimore County, ...and the City of Baltimore is not part of Baltimore county or any other county, bringing Baltimore city to the same rank as a county in the Maryland totem pole. Saint Louis city is not part of Saint Louis County in Missouri, either; Fairfax city Virginia is not part of Fairfax County. The list goes on. Santo Domingo in the Dominican Republic is not part of Santo Domingo province, and Mexico City is not part of the State of Mexico.

 

Standardizing place names and including a reference to a definition of the place will be a big help, for the vast majority of cases, where the location of an event is a community to which the person had a connection at the time. The definition could include the rank words.

 

Merrimack, Hillsborough, New Hampshire, United States

"The Town of Merrimack, in Hillsborough County, in the State of New Hampshire, in the United States of America"

 

Tbilisi, Georgia

"The City of Tbilisi, in the Republic of Georgia"

 

Nashua, Hillsborough, New Hampshire, United States

"This includes both the Town of Nashua and her successor, the City of Nashua; in Hillsborough County, in the State of New Hampshire, in the United States of America"

...because the Town of Nashua became a city.

 

In the United Kingdom, the suffix "-shire" is often used for exactly this reason. This produces the rare cases of needing a hyphen (Ross-shire, Inverness-shire) because we would all just flip right out if the English Language allowed triple letters, wouldn't we.



#38 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts

Posted 27 December 2016 - 01:14 PM

I love standards, but you have to know where your standards are coming from and who controls the standard and the data it represents.

 

Take a look at this effort by a genealogy group in Germany.  Their standards are far more reaching than the one used here.

 

http://gov.genealogy.net/

 

This has the capability of including Churches and exact places on any map.  It is rather European Centric and mostly filled by volunteers, but if adopted by all vendors has far more value than many other coding standards.

 

Also....  And please forgive me in advance for talking about GEDCOM when so many don't really care.

 

The PLAC tag includes the following construct:

 

n PLAC Thornton's Ferry, Merrimack, New Hampshire, United States
n+1 FORM Village, City, State, Country

n+1 MAP

n+2 LATI -71.493611

n+2 LONG 42.866389

 

Any mapping software could take this Longitude and Latitude and create a point.  However I have yet to see commercial software include this "standard" in their database or GEDCOM Import/Export. 

 

These are the reasons that I harp on about GEDCOM, but as I've said:  If the software vendors and the users of the software don't know or care about these things then, I'M OUT because I have no real value in any discussion.

 

No amount of commas can fix this issue in England:

 

The hamlet of Ashton exists in two places in Northamptonshire, England   Nothing other than Latitude and Longitude designations will tell you where it is on a map.

 

 

 

 

I love standards, but you have to know where your standards are coming from and who controls the standard and the data it represents.

 

Take a look at this effort by a genealogy group in Germany.  Their standards are far more reaching than the one used here.

 

http://gov.genealogy.net/

 

This has the capability of including Churches and exact places on any map.  It is rather European Centric and mostly filled by volunteers, but if adopted by all vendors has far more value than many other coding standards.

 

Also....  And please forgive me in advance for talking about GEDCOM when so many don't really care.

 

The PLAC tag includes the following construct:

 

n PLAC Thornton's Ferry, Merrimack, New Hampshire, United States
n+1 FORM Village, City, State, Country

n+1 MAP

n+2 LATI -71.493611

n+2 LONG 42.866389

 

Any mapping software could take this Longitude and Latitude and create a point.  However I have yet to see commercial software include this "standard" in their database or GEDCOM Import/Export. 

 

These are the reasons that I harp on about GEDCOM, but as I've said:  If the software vendors and the users of the software don't know or care about these things then, I'M OUT because I have no real value in any discussion.

 

No amount of commas can fix this issue in England:

 

The hamlet of Ashton exists in two places in Northamptonshire, England   Nothing other than Latitude and Longitude designations will tell you where it is on a map.

 

 

 

 

The example above omits the county, which is Hillsborough County. There happens to be a Town of Hillsborough in Hillsborough County. The Town of Merrimack is not in Merrimack County but in Hillsborough County.  IMHO only when the village is known and overlaps a county line, and the county is not yet known, should the county be omitted.

 

As for churches and cemeteries, data from the U.S. Board on Geographic Names can help with the longitude and latitude, as I show on my website, http://churches-and-cemeteries.com As for standard place names, consider another of my websites, http://gedcomindex.com where you can see the value of standard place names.



#39 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts

Posted 27 December 2016 - 01:40 PM

Also consider the EDUC field. Now known as the University of Maine at Machias, and nicknamed "University of Mickey Mouse" by some, it was once known as Washington State Teachers' College because it is a state college of teachers in Washington County, Maine.

 

The screen shot I saw up-thread assures me that a lot of work has been done defining sub-localities, which is a good thing.



#40 SomebodySmart

SomebodySmart

    Advanced Member

  • Members
  • PipPipPip
  • 112 posts

Posted 27 December 2016 - 02:15 PM

0 @I1@ INDI

1 NAME Karol Józef /Wojtyła/

1 DEAT

2 PLAC Vatican City

 

One of the few cases where no comma is needed IMHO.