Extending SPLAC to include ADDR and PLAC?

[mother10]

Since I started reading GEDCOM, I have always wondered why on some places in the GEDCOM, ADDR had to be used, and on other places PLAC.
Inside ADDR we have tags for CITY, STAE, POST and CTRY.
But inside PLAC we have jurisdictions that do the same?!
On places in GEDCOM, where only PLAC is allowed now, people start using an address as the leftmost, smallest, jurisdiction, because they want to denote an address rather then a Place.
Or they use the name of a church as the leftmost jurisdiction.

Now I have seen the proposels for SPLAC (See #520 and #527 ) of which I want to add to 520 "Adding SPLAC beside PLAC", because that is more in line with what I will write here.
The comparison in that proposel, was made with NOTE and SNOTE.
But I think that should be with REPO and SOUR.
Why?

1 (one) Repository can contain many sources. At an event, we can link to a Source, which can link to a Repository.

I wonder if addresses are not the same.

1 (one) City, can have many addresses. So at an event we should have just an address described, and that address should point to a City (SPLAC). (which in turn points to, a state, which ... etc just as in the new spec of GEDCOM)
The address at the event should NOT have CITY, STAE, POST and CTRY.
Because that way we have kind of the same information on more places in the GEDCOM.

And to maybe make things clearer, we should not call it ADDR, but maybe BUILDING (or an abbreviation of that like BLDNG)
BUILDING can be someones home, or a church or a castle, or a university, a Harbour etc.

Because in 1 home, more children can be born, and in 1 church many children can be baptised, or people can have their wedding, BUILDING should also be a record like structure, not a property of something.

In fact, BUILDING is the smallest form of SPLAC.
It should have a name or a title so it can be identified for a user.

So where ever it is now allowed to have either ADDR or PLAC, we will now have BUILDING there.
That just describes an address in user understandable text. And points to the CITY SPLAC entity.
I looked at addresses around the world, and that seems way to complicated to "catch" in a specification.
So thats why I say, inside the BUILDING, the address is written as complete as the user wants, but that text will only be output by a program (shown to the user), NOT interpreted, it is not used to define where it is on a map, because of the complications.
Defining a BUILDING on a map is done by the link to the "first" SPLAC in the chain.

Now because there can be more BUILDINGs in a City, inside BUILDING we can also use MAP with its 2 coördinates to pinpoint its position in a City.
If that position is not present, it will be put at the center of the city it belongs to (the default position of the City itself). On top of others that have no further positioning.

By adding MAP to BUILDING, it will now also be possible to denote the birthplace when a child is born on a ship or in a plane, or in a car somewhere, because a hospital could not be reached in time. Same is valid for a Death at sea.
So instead of dying in the "Atlantic Ocean", which is so huge we have no idea where that might have been happening, we maybe are able to figure out from the route a ship took, and the date of the death, where it might have been and show a bit better in that immense ocean where it happened.
So BUILDING could also be a Plane or a Boat.

To me I think BUILDING should also have a NOTE structure and a SOURCE citation.

And SPLAC would have a CHAN and a CREA.

Area's:
I remember, to have seen, I think Luther, talking about people wanting an area to denote an event.
That is also possible, we define RADIUS under MAP, and give meters, or kilometers ar anything, and we have a circle with a center, denoting the area where things took place.
1 MAP
2 LATI N18.150944
2 LONG E168.150944
2 RADIUS 5.4KM

Instead of RADIUS we could also have SQUARE or RECT like:
1 MAP
2 LATI N18.150944
2 LONG E168.150944
2 RECT X:+5.7KM Y:-5.7KM
Depending on the + or - the Coordinates denote which corner it is. (Both +, the corner is the left bottom, both minus, that corner is the top right)

But to me RADIUS seems easier.

My guess is this will also reduce GEDCOM size, as a lot of "doubled text" (from all the ADDR's that are in fact the same) will be removed and move into the corresponding SPLAC records.

If BUILDING has a MAP structure and SPLAC too, the MAP of BUILDING should be used to show on a map, as thats more precise. The MAP of a City points to an arbitrary point inside the City. A default point, in case the BUILDINGs pointing to that City, have no Map structure.

In the SPLAC beside PLAC md file, I think there is an SPLAC record missing under RECORD :=
For the TYPE I would choose to have everything in Uppercase, so CITY, COUNTY, STATE, COUNTRY
I think it might be more clear if there also was an example with a real placename.

Maybe, in case of the above example for an Ocean, have a TYPE OCEAN too?
And maybe a Type AIR?
These last 2 Types have no other SPLACs that they point to, or that point to those I presume.

Some other thing about SPLAC:
Now it has coördinates. But what if there would be more ways of denoting a place then just LAT and LONG and an Address.
Then it might need a TYPE to tell what mapping system is used. And maybe more then 1 mapping system can be used for 1 SPLAC?
There seem to be other systems like What3words, UTM coding, Plus Codes, and maybe more.
But that does not seem very common yet?

I am sure I forgot things, but I wanted to add it here, to maybe inspire someone.

[Norwegian-Sardines]

In 40 plus years of using GEDCOM I've never used the Address_Structure! As far as I'm concerned it is useless! But to each their own!

If I need to include an address for a place it is just another entry in the PLAC text. Just like if I need to add a grave marker (because I know the exact location of that marker) I put either the word "Grave" or if I know whatever the cemetery uses to locate the grave (i.e. row, section, columbarium number, "At Sea", etc.)

As far as items that are bigger than a point (Y/X coordinates) we should also have a polygon option in a "PLAC" node.

I also want a TEXT tag that can use a markup/markdown language option to create a formated description of the place being saved!

If I was part of the SPLAC committee these are things I would add, but I'm not!!

[dthaler]

Discussion in GEDCOM Steering Committee 20 AUG 2024:

• Addresses were first added to GEDCOM for submitters.
• Some postal addresses are not "places" per se, such as "PO Box 1234" or "IRS, Kansas City"
• It is common today for many places to have an address, but in historical records it is much more uncommon for places to have a postal address. And agreed that some places have no address like an event that someone died at sea in the Atlantic.
• We are looking at having an open zoom meeting for SPLAC discussion, since we want input from the community before making any decisions. We appreciate this discussion in this and related issues. The proposed date is September 10th, morning in US, late afternoon/early evening in Europe. Watch for a posting in the discussions section of this repository.

[tychonievich]

A somewhat related topic: in my opinion, ADDR is more like EXID than it is like PLAC: it's an identifier, usually defined or accepted by some kind of postal system, for a receptical or recipient of letters and packages. I think that this is consistent with the specification for ADDRESS_STRUCTURE's wording "as it would appear on a mailing label", but could be more clear (or could be an incorrect reading). Like @Norwegian-Sardines I rarely use it and would be happy to use detailed PLAC instead as @mother10 proposes, but I also think that there are cases where a postal address identifier is useful (identifying SUBM, REPO, and postal addresses that appear in sources such the address of a lawyer associated with a legal document)

[mother10]

In my tree, since around 1850 or so, there were a kind of "housecards" used. Those cards were for 1 specific house in some suburb or street (depending on the way they did addressing) On those cards is a lot of important info, names, relations of people living there, dates of birth, when they arrived and left and where they came from or went to. So yes I have addresses in my tree, but only from that time and later. So there should be some way of expressing that. But like Luther said, thats more an EXID thing, street (suburb) and housenumber. All the rest can go in SPLAC's.

Further, as I already mentioned, in the forums of the program I use, people asked to have the leftmost of the PLAC jurisdictions to be an address. Probably for the same reason.

So a postal address is not just for today, for lawyers and such.

[Norwegian-Sardines]

Tineke,

If I’m reading you correctly, these “housecards” sound like Source_Records and therefore assert names, relations, birth dates, residence and other “facts”.

Just like a census that also asserts facts, I would create a Source_Record for the census (i.e. 1920 US Census) with a date of the enumeration and associate it with all of the facts it asserts including the Residence, I would do the same with your “housecard”. In both cases I add the house and street number to the PLAC tag.

In my application we have extended the application to have additional information about each item in the comma delimited PLAC payload that provides detail about the item/location including images and text/history. Meaning I can view information about the division, address, country etc. of any place in my database!

[mother10]

I understand what you say.
But in the Dutch application my data comes from, those are all addresses. Thye are added as "facts" to a person, showing where that person lived with a from date and an end date.
So many Dutch people will have it like this as that program is the most widely used program in our country.

But yes, also a SOUR.

[albertemmerich]

@Norwegian-Sardines:
Let me show why I am using both PLAC and ADDR, even if I have the building in the PLAC hierarchy:

2 PLAC myhouse, myvillage, mycounty, mystate, mycountry
3 FORM building, city, county, state, country
2 ADDR mystreet myhousenumber
3 CONT zip mymunicipality

The PLAC hierarchy is NOT the same as the ADDR hierarchy. I cannot put the ADDR as part of PLAC, as PLAC has no zip code, and as PLAC has the jurisdiction "city", which the address does not have, and municipality is used by the postal address, but not part of PLAC. This is not only theory, in my own postal address you will not find the city, but the municipality. And in the PLAC I do not show the municipality, but the city..

myhouse can be a farm name, or something like that. It refers to the same location as the address does, however the address is like an EXID (see Luther's comment), which - to make it more complicated, may vary from time to time. Some hundreds years ago little villages had no street names, only house numbers. Later the street names were introduced, together with new house numbers. Then the postal code was introduced, however that system has been modified twice since then.

So if we add ADDR to the SPLAC records, we will have an own substructure for the address in the SPLAC record. And that substructure must have a DATE substructure to show the time dependency.

[mother10]

O and the extended information you mention, will now go in the different SPLAC's, that is if they chooses SPLAC not inside PLAC.

[Norwegian-Sardines]

but I also think that there are cases where a postal address identifier is useful (identifying SUBM, REPO, and postal addresses that appear in sources such the address of a lawyer associated with a legal document)

In v5.5.1 GEDCOM, without enough fields to capture enough information about an “artifact source” what I’ve done for documents that were created (like a legal document), the author (AUTH) is the lawyer/writer/scribe of the document and any “location based” information would follow the suggestion for unpublished work suggesting that we use the Source_Publication_Facts payload and input the city, state of the writer of the document!

Maybe Source_Record needs a template for other data just like I proposed from creating a Citation_Record!

[Norwegian-Sardines]

Albert,

The PLAC hierarchy is NOT the same as the ADDR hierarchy. I cannot put the ADDR as part of PLAC, as PLAC has no zip code, and as PLAC has the jurisdiction "city", which the address does not have, and municipality is used by the postal address, but not part of PLAC. This is not only theory, in my own postal address you will not find the city, but the municipality. And in the PLAC I do not show the municipality, but the city..

I don’t understand the difference between a city and a municipality. In Norway, people who live on a farm live in a Kommune not a city, I put the Kommune name rather than a city in the PLAC hierarchy. In the US we have rural townships, I use these when locating a farm, because city does not make sense!

I agree that you need to have an address and zip code, but what are addresses and zipcodes for? Mailing letters! Personally I think GEDCOM should not be used to create mailing labels, but to each their own!

[Norwegian-Sardines]

On the other hand, if you did want to use GEDCOM to maintain an address book, I think putting the Address_Structure inside the Place_Structure is incorrect! I’d rather see it used as a stand alone Fact with a date range rather than as a subtag of all facts, having the zip code and a mailing label address layout for facts like OCCU and CENS makes little sense, most likely you are not going to send a letter (using zip code) to these places!

[albertemmerich]

In my region (Germany) we have:
building
city (the name of village/city where you live)
municipality (the lowest administration level)
county (next administration level)
district (administration level, only in some states)
state
country

In some parts of Germany we have another administration level in between municipality and county.

By the given hierarchy a city is administrated by a municipality.

The postal address in most cases is build using the municipality, not the city (sometimes the names of these levels are the same, then you do not see the difference). And the postal address is build by using street name and house number, not the farm name. The farm name is part of PLAC, a different street name with house number (pointing to this farm) is not part of PLAC.

What are the addresses for? To store this information as it is given by several sources. Like civil birth and death records, books with all addresses of people living in a city in a defined year (like census), letters written from sender and his address to receiver and his address, contracts of two parties identified by name and address. Often the address is a very important information to identify the individual: Someone with same name is living in the same village at the same time. Zip codes are very important to identify municipalities (we have a lot of the them with same name, however in different counties or states).

If you do not document the addresses, you do not need the ADDR. Your decision. If you do document, you need it. And GEDCOM is to transfer all data we collect in our genealogical research.

[Norwegian-Sardines]

I can understand your requirement to record the mailing address in these cases although I would only add it as a NOTE for the fact rather than as a Formatted Mailing Label, because the formatting has less value!

Currently, the Place_Structure and the Address_Structure are not related to each other.

This means that we can record an address {full formatted address as it would appear on a mailing label, including appropriate line breaks (encoded using CONT)} related to the fact that is structurally different than (and independent of) the Place_Structure. This would solve/work for your intended need, recording a mailing address that is not the the same as the location (PLAC) of the "fact".

Adding the mailing address for all levels of the SPLAC binds that mailing address to that SPLAC instance, and for all uses of that SPLAC instances and would require a date driven Address_Structure as well if the "location" stayed the same but some element of the Address_Structure changed.

I would rather see the Place_Structure, Address_Structure and the Shared_Place_Structure all be separate data elements not dependent on each other

[mother10]

Hi all,
Have been reading your comments and thought about them.
I would like to step back and see what we are doing here. (For the "we" read in fact you all)
We started with a PLAC structure and that was cut into separate individual pieces, those pieces could be linked together in a defined way, to form the original PLAC.
Now the cutting gave in fact Jurisdictions, so why were they called SPLAC? Because they came from PLAC?
They are new, not yet existing structures for GEDCOM, so as they are in fact jurisdictions, why not call those JURIS structures then?
To people using GEDCOM that might sound way more logical because thats in fact what they are.
By naming them SPLAC, that sounds like "place" it gives confusion. They are no places in itself, only when together they form a complete string, they form a PLAC.

Chosing the right name for something can help tremendously in understanding new things.
As I said in the starting post, they work like REPO and SOUR, only this time they are not just two steps, they form a whole "staircase".
The bottom step is the position where an event happened, the topmost step is the country where it happened.
To have a correct "staircase" we need a topmost step, 1 or more steps in between, in sequence of area size (as jurisdictions are), and a bottom step.
The bottom step should be the most accurate position we can have for an event.
Often that can be a home, but it can also be a farm or a commune or other things as I mentioned before, and as others stated here. And maybe we only have a placename.

Should the topmost step be "WORLD" because then we can link events on the Atlantic and such, directly to JURIS "WORLD" and we would also have a correct PLAC according to the definition.

Now the "mailing" Addresses. They give confusion, thats why I started by saying we should leave out CITY, STAE, POST and CTRY.
They should be, like Luther said, EXID kind of things. Their contents should be the responsability of the user.
Why?
Because there are so many ways addresses can be written. And its almost imposiible for a program to construct a correct one.
So in case an address is needed for a contract of a lawyer and such, that should go, by the user, in an address, where the address is more like a NOTE with more lines of text, controlled by the user. (as Norwegian-Sardines said)
That address could be used for a letter or parcel to send to, but I dont think it should be the responsability of GEDCOM to check if its a correct address. GEDCOM should treat that as a NOTE.

The other type of address, as I mentioned on the "housecards", they have a street and a housenumber, or, as Albert said, in older times they were just housenumbers in a small village. Maybe we should better call those "Positions".
These addresses/positions form the lowest "step" of the JURIS staircase.

They are not used to send a letter, only to position an event on a map. (Hence I said they all might have a MAP structure)

It can very well be we cannot really locate those "address"-JURIS's (anymore) because we have no idea where that street and housenumber might have been. They could be destroyed for some reason (flood, bombing, anything) or might have disappeared because new houses were build there.
But no matter what, those smallest JURIS's (Positions) are the bottom step in our PLACE staircase.

Maybe we dont know the smallest JURIS, and we only know the City, then that is the lowest step of the staircase.

As @Norwegian-Sardines and others said, the way of addressing a "position" varies much accross countries and even inside one country. The sequence of the steps is not the same everywhere.
So the JURIS's should have a TYPE, same as the jurisdiction names in the PLAC statement has now.
Extra TYPE's are needed because of the variations in the countries for jurisdictions. (Like Municipality, CODE-Insee and more.)
In 1 "staircase" each TYPE is only allowed once. The sequence of the TYPE's is the users responsability.

JURIS should have the possibility (as Norwegian-Sardines mentioned) to store extra information to describe a city or a state or more. Adding pictures should also be possible.
If we define something new, lets think carefully about what should go in there, so we dont have to add forgotten things too soon after the release.

I would like to add 1 extra TAG here.
As the PLAC is now, with jurisdictions that can be empty, that gives users sometimes placenames like:
, Den Helder, ,
So with "empty" comma's.
Now the same as the proposal for the new NAME structure has a TYPE "RUFNAME" to denote which name should be underlined, I would like to propose a TAG CITYNAME (or alike) to denote which of the JURIS tag names should be presented to the user.
This tag is only allowed in 1 (one) of the steps in the JURIS staircase.

[Norwegian-Sardines]

I'm still going through all of what you wrote, so I'll answer smaller bits as I find them!

Now the cutting gave in fact Jurisdictions, so why were they called SPLAC? Because they came from PLAC?
They are new, not yet existing structures for GEDCOM, so as they are in fact jurisdictions, why not call those JURIS structures then?
To people using GEDCOM that might sound way more logical because thats in fact what they are.
By naming them SPLAC, that sounds like "place" it gives confusion. They are no places in itself, only when together they form a complete string, they form a PLAC.

For me (and maybe this is just my interpretation) a "Place" does not stop with "jurisdictions"! If I have a BURI fact I also want to have a place to record the location of the exact grave marker. I the software I use we can map to a specific spot on the map include the exact location of the grave. The same is true for RESI (residence) I want to include the street address or farm name in the PLAC tag and map that location. This is why I've used the SPLAC tag, it is a "Shared_Place".

In addition, a place can have multiple parent places. Let's take an example: The city of Gdansk in what is not Poland was for a time part of the Prussian Empire and before that was officially in the "Kingdom of Poland". Individuals born in various parts of Poland during times of annexation and control could have birth certificates stating Prussia. The hierarchy for Gdansk should include all possible parent jurisdictions with From/To dates. My own grandfather was born in "The Hungarian Empire" the town has changed names but it is now in Serbia! We need alternate names with date-range (from/to)!

One other reason I want to have separate SPLAC nodes is so I can associate formatted text with the node to describe the place for my readers who are not "history people" but still may be interested in the history of the place, be that place a farm, city, country.

We could name SPLAC something else but my vision is to deprecate PLAC at some point.