Fields for specific institutions/locations

LegacyUser

Jane Gramlich said: Please add fields for the specific institutions/locations where events took place, for example, church/temple names, cemeteries. Even though the standard is to go to FindAGrave for cemetery names, that involves extra links and steps and it would be easier to see that information in a person's profile. Besides, FindAGrave might be inaccurate or further explanation could be needed.

LegacyUser

Cary Holmquist said: Thanks for asking for this type of feature! I have wanted something like it for a very long time as well, but did not know how it might be designed.

LegacyUser

Gordon Collett said: A separate field is not needed. The name of any institution can be added to a person's profile now by adding them in front of the place name like this:



To enter the name, you do have to type out the entire place name if the institution is not included in the standardized version. When you have completed typing in the name, it will be the first choice in the drop down menu:



Click on that top line to enter the full place name and set the standardized version (which will be less complete):



However, many church and cemetery names have been added to the place name standards database and more are being added all the time. These will show up as you start entering the name, allowing you to pick them off the drop down menu directly:

LegacyUser

David Newton said: Yes an extra field is needed for street address information. The places database will simply become unwieldy if the current path is continued. If churches can be added to it why not ordinary street addresses? Besides it isn't just it, it's eventual automatic translation of place names. The only way that is if the place field contains the place name in a standard form and nothing else.

LegacyUser

Gordon Collett said: David, I know we have completely opposite opinions on this, but I'll just explain myself again so that Jane knows the two sides to this topic of place names.

We do not need a separate field for additional sections of place names because we have an huge number of fields already. Each comma designates a new field.

You can see this demonstrated in the Places database which contains the standardized forms of all the places currently included.

Take, for example the farm Røydland.
https://www.familysearch.org/research...

This is a unique place in the database. It is attached to three other unique places so that is is found in the standards list as:
Røydland, Stord, Hordaland, Norway
Røydland, Fitjar, Hordaland, Norway
Røydland, Fitjar, Vestland, Norway

Stord, Fitjar, Hordaland, Vestland, and Norway are all separate entries in the database and when entering Røydland as a full place name, you are actually designating four different fields. Adding a fifth, sixth, seventh, or more field in front of them is handled just fine by the software. For example, one subsection of the Røydland farm is called Dalen. I can enter Dalen, Røydland, Fitjar, Hordaland, Norway as a five field place name with no difficulty at all.

As far as eventual translation of a name goes, additional fields should be no problem at all. All the translation routine has to do is parse the original field by field, that is, comma by comma, and translate the individual fields. If you look in the Places database, it is the individual components that exist in different languages, not the complete name as a single unit.

In my example, any translating routine should do the following:
1) Dalen: not in standard - ignore
2) Røyland: in standard - exists only in Norwegian, never needs translation.
3) Fitjar: in standard - exists only in Norwegian, never needs translation.
4) Hordaland: in standard - exists only in Norwegian, never needs translation.
5) Norway: in standard - exists in multiple languages, has equivalent in requested language - translate to requested language.

So Jane, do go ahead and make use of the multiple place name fields we have and enter just as much as you need in front of the "standardized" portion of the name.

LegacyUser

Tom Huber said: For United States' locations, cemeteries are in the standards list.

Street addresses are not, but can certainly be entered for a place name.

The place name does not have to agree with the standard (and should not if a street address in included in the Place field by the user).

LegacyUser

Jeff Wiseman said: For death and birth records, Many hospitals are in the standards list as well. I love the way this places database is evolving. The only problem is all the people out there that don't understand how it is supposed to work.

A "Standardized place" really doesn't have that much to do with spelling as it could be different in other languages or different time periods. It is a predefined "place" that has been assigned a given geo-location set of coordinates.

It is a physical place that may have a number of different names assigned to it at different times in history.

LegacyUser

Paul said: Gordon's suggestions lead to the best way around this problem. Personally, I'm not bothered about having a detailed address in the vitals' fields. The fact that your ancestor/relative died (specifically) at 10 Rillington Place, say, can be recorded elsewhere.

Surely the inputs to the boxes in the Vitals section are primarily to help the Search function produce better results?

LegacyUser

Jane Gramlich said: I understand that database technology can allow for an unlimited number of subdivisions. It's more of a conceptual issue to me - unlike Paul, I've been bothered by specifics in a standardized place field - I took standardized places to mean only historical or existing geographical locations/political jurisdictions. That's been complicated enough to keep track of and I felt that an additional field would allow for some flexibility and help keep the concepts separate. But if the places field is evolving to include specifics that are considered standards, I'll work with it. Thank you.

LegacyUser

Gordon Collett said: Yes, the details of a death place can be recorded elsewhere, but why when there is a perfectly good, obvious place to record it right there labeled Place of Death?

LegacyUser

Gordon Collett said: In FamilySearch "standardized" place, does not and never has meant "the one and only way to record a place name." It means "the dot on the globe where something took place no matter what you want to call it." This is a very powerful tool that I don't think exists in any other genealogy program I have seen. FamilySearch allows you to put as much detail in a place name as you wish, use the best format for place name depending on the situation, and still designate the correct geocode for the place. The "standardized" version is merely the latitude and longitude in text. And, of course, when an existing standard is sufficient, a quick way to avoid spelling errors.

I haven't posted my full explanation of this great dual entry model for dates and places in a while, so I will again for you to look at if you like (even though I know David doesn't like it and doesn't agree with it). This presentation is completely my own opinion. Don't blame FamilySearch for any of it.

https://docs.google.com/presentation/...

LegacyUser

terry blair said: Write a comment...

LegacyUser

terry blair said: Jane, I see that some people agree with your feelings in that they are removing cemetery names from burial locations on a number of records that I watch. In one case I had to laugh, although I don't think the city fathers would agree, because by removing the cemetery name in favor of the city name alone, the geocodes were changed such that the burial was placed in the middle of city hall. Now consider that there are about 7000 burials in that cemetery, using only the city name would result in a really tall city hall.

LegacyUser

Jane Gramlich said: Hi Terry - guilty as charged - I've been removing specifics because I felt they didn't belong in the field, but doing that also bothered me because the information is so valuable. I'll avoid that now and work on restoring them as I come across them.

LegacyUser

Gordon Collett said: By the way, this ability to add to the "standard" version of a name is vital in many parts of the world.

For example, the parish of Austevoll in Hordaland, Norway contains one place name in the standard list.

The parish of Stord which is close by and is about the same size in both area and population has 141 "standard" places within it.

Until all the sub-places needed in Austevoll are added, sticking with the "standard" would be like only being able to record a county level place name in the US and always leaving off the city.

This is really bad in Norway where you might have 10 Ole Olsson born the same year in Austevoll, each at a different place within Austevoll. If you don't include the actual place in Austevoll right there in the same place name field, it gets really easy for people to think they are duplicates and mis-combine them.

LegacyUser

Jeff Wiseman said: The boxes in the Vitals section are NOT "primarily to help the Search function". a location field there is the full location of a specific event that occurred in that person's life. It is a CONCLUSION that has been derived from multiple sources documenting a given vital.

The fact that using parts of those fields in order to search for other sources leading to other conclusions is only a nice by-product of those fields. Their PRIMARY reason for existence is to document conclusions for vitals. Therefor, a place should always be as detailed as possible, and placed in ONE location such that "pieces" of the location description are not scattered all over the database.

Reasons for change, discussions on sources, collaboration Notes, Conversation messages are ALL precursors to CONCLUSIONS that are then documents in the vitals area. E.g., there needs to be one and ONLY one field where the description of an event place exists so that there is never any question of where a person needs to look to find it. Hacking it into pieces and scattering it throughout various places in the person's record only adds entropy and confusion in the system by not having a consistent structure for the database.

If you want to know where someone was born, you should never have to look anyplace else other than the BirthPLACE field. Any other considerations or derivation assumptions for that vital belong elsewhere--Usually the Notes area.

LegacyUser

Jeff Wiseman said: After someone has spent so much time identifying details for many locations and someone has gone through and deleted all of that information, it is pretty irritating. I even know of FHC consultants that have been telling people that the locations must all have the map pin icon by them, so they are teaching people to remove the greater details in the vitals section simply because it doesn't have map pin icons next to them.

Frequently the administration address for a cemetery is in an adjacent city and township. As a result, a lot of cemetery locations in places like Find a Grave are actually WRONG! If you were to take the actual location name given in find a grave and use it instead of looking closer, you can get a geographical marker for the cemetery that is maybe 3 miles away from it. Furthermore names and ownership of those cemeteries also change over time just as the township and village boundaries around them change.

LegacyUser

joe martel said: Jeff and Gordon have it correct. The vital conclusions, like Birth supply all the info regarding the place that the user should have to look at. The event conclusions have a user supplied value and a standardized value. So you could have 123 N. State St., Provo, UT for the user value and then choose the Provo, Utah, Utah, US as the standardized value. The user can interpret the user supplied field and the computer has a standardized place locale to use in things like the search algorithms. 

LegacyUser

Jeff Wiseman said: As Gordon points out below, that feature is already implemented.

LegacyUser

Jeff Wiseman said:

If churches can be added to it why not ordinary street addresses?

Because in a small town there may be less than a dozen churches but there is thousands of individual street addresses.

The dual field standardizing technique in FS is amazing. At the top level (e.g., countries), there will always be a geo location at various times in history. At the bottom level (e.g., apartment and street name and number) will almost NEVER have a Geo point assigned to it, so you get the closest point (e.g., a city), and then add the details that don't have their own co-ordinates. That is how you "Standardize" a street level address.

It's a great system that can be standardized down to a given level, and below that you can have the freeform text. It is the best of both worlds IMHO.

LegacyUser

Jeff Wiseman said: Here's an example (note that this cemetery is a standardized location):

LegacyUser

Jeff Wiseman said: Indeed, we should NOT have a separate field.