UK and Ireland addresses
Standard places do not reflect how people from their countries actually address nor do they use respective post codes {zip codes to out USA friends}.
about Ireland
e.g. 1 County Galway should be referred as Co, Galway {i see USA counties already does this!}
e.g.2 In Ireland impossible as it is , townlands spelling names change over times !!! Better to use eircodes and there is a unique one property even though old demolished buildings will have to use Eircode of nearest existing building. That will not be a problem to the irish
about UK
County names have standard abbreviations and the full name is not used! Postcodes refer to small section of a street
e.g. 1 Northamptonshire is Northants
e.g. 2 Yorkshire is Yorks
Willing to help further with this
Comments
-
As far as the UK is concerned, I just read there are over 1.8 million postcodes currently in use!
Would you expect FamilySearch to add all these and (for Ireland) Eircodes (either with or without the unique identifier part)?
On the issue of counties, it is no longer necessary to add these with the postcode when sending letters in the UK. So whether the county is referred to as "Yorkshire" or "Yorks" is no longer important.
The real issue with the standard placenames database is in (eventually) having one location that relects how the place is known as today and how it has been known as at different periods of time. The important thing is that all standard placenames should be added in such a way that makes is possible to associate the location with its correct position on a map.
2 -
The real issue with the standard placenames database is in (eventually) having one location that reflects how the place is known as today and how it has been known as at different periods of time. The important thing is that all standard placenames should be added in such a way that makes it possible to associate the location with its correct position on a map.
FamilySearch Places Standard/Authority/Database does have this capability - i.e. associating different placename(s) with differing time periods -but as you mention is far from complete - thus provides opportunity for any wishing to contribute.
General topic comment:
Additionally the FamilySearch placenames database - as I understand it currently - has one Display Name (which might be localized into different languages - but just one display name for each language). I assume this Display Name does reflect the current time period common name - so I don't know how that might relate to mail codes (if those are even more commonly known). I do not see a Places database option for associating current mail codes. I think I vaguely recall this issue having been brought up before - but I do not recall the result/FamilySearch response.
Perhaps this question/Idea can be brought up in Places Community Group to see what kind of response is received?
1 -
Overall, abbreviations are a bad idea so even though currently counties are abbreviated in general usage, it is best to spell them fully out in Family Tree. One or two hundred years from now there is a good chance no one will know what those abbreviations meant.
Yes, I fully expect Family Tree to still be around then.
If you feel it is best to include mail codes in place descriptions, feel free to include them. You will still be able to properly link the appropriate higher level standard. I add addresses to place name when a census contains them and add plot designations to burial places. It works just fine.
3 -
Gents,
any developer like myself who has developed embedded address databases know the only sensible solution is to use and indexing system like the postcode. Having an address system expecting the user to enter data in a format that is incompatible with what is accept norm amongst the user is best problematic.
In the UK there is only been a few significant county reorganisations and finally ended up with and sensible index system called the postcode!
In Ireland the problem is much worse! The final solution is one Eircode per property and maybe a little too fine. The problem is worse because of the anglicisation of Irish townland names varies with each clerk or clergy! The names of each townland do not vary necessarily with time zone but by who actually record the event
0 -
You may be right about Eircode being the current day norm - I don't know.
It wouldn't be the first time FamilySearch has been called daft. Now when you reach the point where FamilySearch/Community calls you daft - then you've really achieved something ...
But the thing is - as Gordon mentions:
If you feel it is best to include mail codes in place descriptions, feel free to include them. You will still be able to properly link the appropriate higher level standard. I add addresses to place name when a census contains them and add plot designations to burial places. It works just fine.
What's the problem with just entering the address you would like? Now, if you can - or some other user not knowing Eircode - decipher that to a Standardized place is another matter... Yes it would be nice if the database already understood.
... But who's saying it can't? The database is based on finding/entering placenames from records - thus capturing names at certain time frames. Poke around the places link above to understand how it currently works - especially the Suggest an Improvement database fields.
So if you are saying all current places in Ireland should include Eircode - that sounds like a simple thing to add to the database ... But you really need to convince FamilySearch Placenames Authority management - your idea here in Community - if not understood nor gaining 'likes, support or votes' will probably remain unheeded.
I suggest you produce a simple prototype/demonstration of your Idea and attach as gif or link - so that it can be more convincing. I am running into the same problem with my GEDCOM ideas - apparently they are not understood ... So I'm trying to work on a prototype/demonstration (but keep distracting myself here in Community).
1 -
- Presumably standard places are to match documents! its very simple standard places in FamilySearch do not match what is actually in the documentation for both in the UK and Ireland !!!!!!
- Presumably standard places are to get new addresses from users in a standard format but in a different standard that the user understands or in commonly used is very problematic . In my 50 years of SW development this has never worked successfully!
- String pattern matching like address matching is very difficult at the best of times and even more difficult when these actually change over time. Trust me FamilySearch developers have my complete sympathy. this why we usually link multiple data points like addresses to an index like the postcode/eircode or zip codes and then match the indexes first .
- I have corrected several 1000s of UK and Irish addresses into standard places and being to realise this is futile because of what i have said above. Its a core design problem of many apps and I encourage the team here is find out best practices adopted elsewhere including uses are government address dbs. I fully admit there is no right solution but I firmly believe we can improve a great deal
0 -
@PaulHarrison61, FS has moved away from string-based matching for both places and dates. That's what the places database is fundamentally for. (One result of this move is the current and ongoing autostandardization mess. I shall restrain myself from even getting started on that.)
I disagree (strongly) about postal codes in a genealogical places database.
Postal codes are overwhelmingly a 20th century phenomenon. Most places on the planet never heard of them before mid-century, if then.
Genealogical records, on the other hand, are overwhelmingly 19th century or earlier. They predate street addresses in many places, never mind postal codes.
The genealogical ideal is to record events according to what was true at the time of the event, because that is a static fact, and it determines what types of records were created about the event. Therefore, a genealogical places database needs historical jurisdictions, not modern ones, and postal codes are totally irrelevant in it.
3 -
Limited by time...
1. You will need to give examples of what you mean - as far as I know - many standard places in FamilySearch Places match. If a place doesn't have a standard - you can submit one for review. If you have a problem with one you can Suggest an improvement - but are limited to the fields for such. If you have an Idea to improve the Suggest an Improvement fields (which is what your Idea sounds like) - you need to convince FamilySearch here in Community (which you are attempting to do).
... As Julia implies the places are coordinate based. So theoretically you could also include postal codes - but I don't think there is an existing field for it because as Gordon mentions you can already include such a in freeform entry and associate that with a Standardized place ...
That said ... I'm all for discussing Ideas that might produce improvement.
0 -
As Julia indicates, there is a gap in time between many genealogical facts and today's post codes, etc. Recently, I was trying to work out reasonable co-ordinates for places in the Manchester suburbs that were flattened during either WW2 or subsequent slum-clearance. The straight copy of the 19th century address is easily done - it's just text. Turning it into a spot on today's map could be seriously frustrating and I doubt many would bother trying / would be daft enough to try. It's not just individual buildings that have gone but the complete street pattern.
1 -
@Adrian Bruce1 sounds like what you need for Manchester is a great feature the Norwegian mapping bureau provides. Their historical map service lets you put historical maps over current maps and adjust the opacity to see exactly where things were. This is a section of Oslo that was just countryside in 1804. Now a major train station is sitting where a river used to be:
I think there are some databases for the US that do the same thing. Is there anything like this that someone has put together for England?
1 -
@Gordon Collett - there are numerous sites that simultaneously show both old and new maps for the UK. Unfortunately, while some allow layering of the old and new, with adjustable transparencies (as per your Oslo example), the Manchester maps (that I was using - there may be others!) do a split screen approach with old on one side and new on the other, which I find harder to use, as inevitably I seem to need a whole view on both sides of my chosen vertical division in order to recognise things.
But I do like an old map!
0 -
Thank you for your replies. Just to point out the main aim of this app is to map sources to the family search database of individuals. To do this mapping it is usually easier and beater the app bends towards the address data its trying to map and the way users perceive that address rather than trying to enforce a unnatured FamilySearch data format from the app on the data sources or the user!
The other source of information is living people with their perception of address format and forcing an unnatural standard place on them will yield poor results. I have updated thousands and thousands of records correcting this! Surely some automation could correct some of the simpler address issues and maybe a suggestion report for a human interaction could be done as well.
I appreciate the app was written originally for the USA people but as a relatively young country even people of the USA have to go outside the USA after a few generations.
0 -
I appreciate the app was written originally for the USA people ...
No it was written for FamilySearch users - which reside all over the world. This is seen through the population of the database...and the fact that improvements are submittable from anywhere (not just users from USA).
To do this mapping it is usually easier and beater the app bends towards the address data its trying to map and the way users perceive that address rather than trying to enforce a unnatured FamilySearch data format from the app on the data sources or the user!
I do agree that pinning a place on a map can be easier to understand than a freeform text entry of a place - as long as one has such coordinates - other than this, I'm having difficulty understanding what you mean.
Royal Mail post codes are copyrighted. They are also covered by database right.
So that prevents their use? Interesting... I mean I haven't investigated - but the implication would be that anytime such postal code were used the 'right' holder would be due some 'royalty? If facts are copyrightable then I might have a few ... 🤔 ... But I 'work' for a 'living' ... That's a pretty nifty scheme ... But I guess that's government.
I guess we are getting into international law here ... definitely not my forte - but yes might affect how FamilySearch is able to implement some aspects of data ... I guess. ... But it's ridiculous in my opinion.
General topic comment: I like the flexibility of FamilySearch Places Database/Standard/Authority. You are allowed to enter a freeform text entry (either a placename as you know it or that you find on the record) and associate that with a Standardized placename from the database/authority. If that place is one of the acceptable place types (cemetery, church, etc) you can submit it for entry if it's not in the database. If it is not one of those places types - you can use the freeform entry method.
I don't know that we need to have layers upon layers of different embedded areas (postal codes) for different time frames - but I do understand the point that current documents/mail would be addressed with such. So if FamilySearch wanted to use postal/zip codes as a 'place' mapping layer - they could (I guess as long as there weren't copyright/trademark entanglements - because yes - submission of such data would be covered by FamilySearch Terms of Use). Or if deemed complimentary (in purpose) - they could make an agreement with such 'governing bodies'.
But to a layperson wanting to document Family Tree (noncommercial use platform) - I think it's pretty ridiculous to want to charge for use of a sequence of letters and/or numbers - that if someone had such correspondence was already 'paid for' when originally sent.
If I am not understanding - feel free to enlighten me.
0 -
Places in Family Tree really have nothing to do with how the postal service wants people to mail letters. And besides, my ancestors living in England in the 1700s certainly did not have postal codes and putting them in a place name would be terribly anachronistic.
It appears that once again the topic of standard places and the use of standardization in Family Tree and how these concepts are misunderstood has once again come up. I'll try and keep my contribution short and not get carried away like I usually do.
The purpose of the FamilySearch Places database is two-fold. Firstly it is to assign a list of historical names with proper time periods and proper jurisdictions for each of those time periods to geographic locations based on latitude and longitude in order for the various routines in Family Tree to use latitude and longitude when comparing records. Secondly it is to function as a speed entry system for users of Family Tree to be able to pick, when appropriate and available, the proper historical name for a location without needing to type it out completely.
The Places database, however, only goes so far in pinpointing locations. In general, the lowest level is going to be a village, town or city. I don't think it will ever go down to the level of streets or individual building. That fine level of granularity is not useful in search routines and would turn one entry in the database for London into millions of entries. That is just not practical and due to the structure of Family Tree, it is not needed.
This is because FamilySearch is not "forcing an unnatural standard place" on anyone. Everyone is at complete liberty, within the boundaries of interfamilial cooperation, to enter place names in whatever manner their family information requires. This is possible because of Family Tree's dual place entry system in which all place names are entered as both free-form text and as a linked standard.
If someone wants to include a postal code and enter an address using modern abbreviations rather than the actual geographical name for a place, they can even though abbreviations are alway a terrible idea.
As an example, Google states that the address for the Leeds Central Library is Calverley St, Leeds LS1 3AB, UK. You can enter this as a place name in Family Tree and standardize it just fine:
This place name will work perfectly fine in all FamilySearch routines. But why use it? Why make everyone go look up an obscure, meaningless in and of itself, code that won't be used at all fifty years from now? Why not make things easy for your grandchildren and just put in:
3 -
See the difference in whose content is 'in alliance' ... When essentially nothing different in content was shared? That's fine - play the Community game ...
0 -
One additional thought I had that I think has bearing on this topic. I would maintain that the places we enter in Family Tree should be how the person for whom we are entering data would answer the question, "Where do you live?" That is a different question than "Can you write me down your address?"
I assume that if you asked someone who lived in Dorset where he lived, he would never say "Dor" and he would certainly never say "DT" either in the past or today.
1 -
mapping is a mathematical/ data process! { not a just topological illustration of geography!}
An unique index key is often used as a primary key to reference a database table. When I used postcodes as an example only!! To many peeps here only hearing way they want and are obsessed with postcodes. They were given as an example as index
Sorry when I posted my ideas I thought I was talking to developers who understood data models and database design.
The ONS in England for example have a very interesting solution using predictive matching with data science.
Swilson.info in Ireland has come up with a very good solution to Irish townlands a even worse problem with a a largely unwritten down Irish names that have brutally analgised many different ways depending on the ear of english speaking clerks!
This is a real problem of matching unstructured text to another piece of unstructured text and the real problem FamilySearch needs to solve best as possible to be successful!!!! Its the nature of the beast taking hand written records done differently clerk to clerk, done differently in different eras and matching them to some said data format!
0 -
We users have been assured multiple times that all posts are sent off to the proper development teams as appropriate. I assume that anything useful in follow up discussions are, also. However, the developers rarely reply to anything unless they have initiated a post specifically requesting feedback as is occurring in the new Person page group.
The benefit of the community discussion is to clarify and refine ideas posted. A bit of friendly friction can turn a vague post into a specific one. Based on your most resent post @PaulHarrison61, it now appears that three very different topics have been conflated and confused here:
- The underlying structure of the Places system to identify places.
- The textual standards used as an overlay of that structure for ease of use.
- The free-form text entry for place names that allows full identification of a place which then needs to be linked to a textual standard.
Do I understand correctly now that you are only talking about the first topic? The underlying unique key that actually gives structure to the Places database? (https://www.familysearch.org/research/places/)
If that is the case, I would be interested in understanding the disadvantages of FamilySearches current system which is simply latitude and longitude. These geocodes, which go out to four decimals and so can be very accurate, are predetermined for everywhere in the world, are applicable to all countries, are independent of the decisions of any one country, will never change, and can easily be used for any calculations.
The system seems to work quite well.
1) Any latitude and longitude can be entered in the database as the primary index key for that entry. This is what all FamilySearch routines actually use in all calculations.
2) All the latitude and longitudes can then be assigned as many textual representations for that place as needed to describe that point on the globe at any point in history. These names are what users see as "standards" so they don't need to go look up where a particular latitude and longitude is.
3) Users are able to add just as much additional information to a place name as they need for clarity and precision then link it to an appropriate standard which applies the latitude and longitude for that spot on the globe thereby uniquely identifying the user entered text.
What better system than latitude and longitude would you suggest that can be universally applied?
3 -
Hi. This thread has been edited and closed due to code of conduct violations.
0
