Question Two place requests

Noting our occasional discussions about what the place used to be called and what it used to be part of, vs. current geopolitical situation, what if …
GEDCOM compliance were relaxed a little to support something like Currently, this can be entered via raw GEDCOM, and then both places and the types will show in the GUI editor. But on the facts tab, only the second is shown, without a type.

---

The other is merely to go ahead and support level zero places. If the syntax is exactly the same as the level two version, it would be trivial to replace the xref on export/download. (Could make that an option, for when the user knows the file is intended for webtrees.) similarly, trivial to create them on import, detecting and merging duplicates. (No need to get fancy, if it differs by a single character, it’s up to the admin to handle it—let the merge function support them.)

I know Greg has some sophisticated ideas for a really robust places system, but this seems to me like it would be relatively easy.

I thought the standard allows only ONE PLAC tag per event/fact

Stephen

I guess that's what Wes means by "...what if …GEDCOM compliance were relaxed a little "

I think the idea has merit. If combined with rather than alternative to implementing Level-0 PLAC tags it could be useful. Certainly far simpler and more intuitive than any other solution I've seen described so far.

I'm not sure what having two PLACe tags in, for example, a birth event is indicating.

Are the two PLAC tags indicating,

A) the individual was born in "Hutton" but maybe "Salisbury"
born in "Salisbury" which is now "Hutton"?
C) born in "Salisbury" but no place like that is known so I'm calling it "Hutton".

In general two successive tags of the same type following each other within the same context says that the first one is a "preferred" value and the additional ones are "secondary" and in decending order of preference. All tags except for the INDI.NAME tag work this way, so I'm inclined to think "A", in the above question.

BUT... if "B" is what you are indicating in the representation, do I list all AKA values? A birth record where the person was born in Berlin, Germany. Do we also then have to list: 1) Berlin, East Germany 2) Berlin, Kingdom of Prussia 3) Berlin, Weimar Republic 4) etc... And do I list them for all PLAC tags where the event occured in Berlin?

From a database standpoint this data is so not normalized, as to make me gag.... So I'm inclined to think 0 PLAC

Therefore it is better to list the value as follows:

1 BIRT
2 PLAC <place in source>
3 _PLAC @P1@
2 DATE ...

So that the documented value (the place name found in the source) is listed directly with the event it is supporting, then a cross_reference tag says "look here" for additional information of this place.


The zero level place_record could then take on the look and feel of the INDI (individual_record) with AKA names, location polygons, historical documentation, etc.

0 PLAC @P1@
1 NAME <place name hierachy 1>
2 DATE FROM ... TO ...
1 NAME <place name hierachy 2>
2 DATE FROM ... TO ...
1 Mapping information, history information etc.

This is a more "normalized" way of listing names. Although it only presents a very limited chance of "reuse" as noted by Greg in the other thread. To keep up with GEDCOM usage you should then have cross_pointers so places can be reused.

Berlin could then point "up" to Germany, Kingdom of Prussia, East Germany, etc. AND they could point "down" to Berlin.

The two ideas are not alternatives to each other, nor are they dependent on each other.

Allowing more than one PLAC on an event is an attempt to placate (pun intended) the lament about having to decide whether to use the name at the time or the name now.

The choice of "TYPE" values to be allowed would have to have to be more carefully designed than my hasty posting of "original"

I don't intend for either to be "preferred"--don't use the spec to analyze a deviation from the spec. (But, if you want the first to be preferred, then maybe it's a bug for webtrees to display only the second.)

And I thought I made it clear that I was suggesting a simple thing that could be done now without in any way denigrating Greg's ideas for a future sophisticated place hierarchy. It's kind of silly to criticize the fill-in for not being the thing it's filling in for.

As for "normalization"--it has its place, but it is greatly overrated in some circles.

I completely disagree with trying to make a level zero PLAC some sort of imitation of an INDI. Make it EXACTLY the same structure as the level two that it comes from--and must be returned to for GEDCOM export. I'm offering something SIMPLE while the better and more complex is not available. If we have to make it more complex than what it's filling in for, there's no point.

Now, IF this were adopted, I suppose it could evolve into something more complicated, like having its own pointers to enclosing places, date ranges where it's OK to use it and other complications. But I'm not looking for that. I'm looking for something SIMPLE that can trivially be reverted to legal GEDCOM. The level zero idea, that is. Certainly not trivial to make a double PLAC legal.

Wes,
I work around the historical names issue by noting the historical name at the lowest level, making it a virtual component of the larger current structure. As per your example:

That imho is simple to do and not bending the GEDCOM rules too much.

Wes,

Please don't be offended. I'm looking at this from a design standpoint of making a change that can built on into the future as opposed to used for the short term with a better solution later.

So if all your are looking for is a way to present the "at time of event" place vs. "present time" place maybe a better alternative can be found, like:

1 EVEN
2 DATE ....
2 PLAC <present time place>
2 SOUR
3 PAGE
3 DATA
4 TEXT <full text from source>
4 _PLAC <at time of event place>


-or-

1EVEN
2 PLAC <display place>
3 _PLAC <alt place>

-or-

1 EVEN
2 PLAC <at time of event place>
3 MAP
4 _PLAC <present time place>
4 LATI
4 LONG


Just some alternative thoughts.

I use this today:

1 EVEN
2 DATE ....
2 PLAC <present time place>
2 SOUR
3 PAGE
3 DATA
4 TEXT <at time of event place>

norwegian_sardines wrote: Wes,

Please don't be offended. I'm looking at this from a design standpoint of making a change that can built on into the future as opposed to used for the short term with a better solution later.

So if all your are looking for is a way to present the "at time of event" place vs. "present time" place maybe a better alternative can be found, like:

1 EVEN
2 DATE ....
2 PLAC <present time place>
2 SOUR
3 PAGE
3 DATA
4 TEXT <full text from source>
4 _PLAC <at time of event place>


-or-

1EVEN
2 PLAC <display place>
3 _PLAC <alt place>

-or-

1 EVEN
2 PLAC <at time of event place>
3 MAP
4 _PLAC <present time place>
4 LATI
4 LONG


Just some alternative thoughts.

I too struggle with many places that have historical & current names. However, the suggestions I've seen present the problem of remembering syntax when it comes to entering the PLAC on a record. How did I do it last time??????? That's how I find my inconsistencies.
So far I've used
2 PLAC Berlin [Kitchener], Ontario, Canada
where the event occurs before the incorporation of the city of Kitchener and
2 PLAC Kitchener, Ontario, Canada
where the event is after that date

Problem occurs when there is no date for event or reading through the "Wiki" (or whatever) is long and confusing to determine what to use when.

design standpoint of making a change that can built on into the future as opposed to used for the short term with a better solution later.

i guess I should have restated this earlier: short term was exactly my intent. The better solution has already been discussed and Greg has already experimented with it. On the other hand, there are ways this could be enhanced. But people are wanting the maps module to support both place name at the time (I almost used “at the time” for the type) and current place name, hence the multiple PLAC relaxation. (In answer to one of the other questions, you put in as many PLACs as you want. I said relaxing rules, not adding more of them.)

And people are wanting to put more info on PLACs without having to keep re-typing it. So shared PLACs have been often requested.

I am merely suggesting what seems to me a not-difficult way to quickly get much of what is desired. As a developer (of other software), I have no objection to giving my users something so-so but usable that we will throw away when the good stuff is ready. Often, that is a better approach than “No, you can’t look at billing productivity until it’s perfect.” And sometimes a working bicycle is preferable to a Cadillac that you know is going to blow up in the middle of nowhere.

The approaches of making one place subordinate to another do not satisfy the people who want the maps module to support both of them. And neither of these suggestions will take away anyone’s ability to look at “how did I do it last time?”

Macalter’s idea of putting the historical name in brackets is a good one though. Users of maps would still have to put both forms in the places table.

Wes,

Now that I understand your focus, I would say that your solution works except for a few minor issues that would need to be resolved.

1) Point Overlap: On maps when two points occur at the same LATI/LONG (the primary use of this workaround) the points will overlap on the drawn map.

2) Migration: If we suggest and allow the use of multiple PLAC tags we should probably provide a migration utility to get users from this design to the next.


If this is a GM Module issue I would advocate a different strategy, make a small change to the GM interface or GM database.

First I'm not sure where GM gets the display value for the little popup on the map point. I'd have to look at the code to say which path below would work.

1) if the display value comes from the GEDCOM then I would rather have the tags look like this:

2 PLAC <place name 1>
3 _PLAC <alternate place name>


This would allow for the GM module to have one location to gather it's display information by first using the standard PLAC tag to look up the LATI/LONG in the GM module location database, then constructing the display by concatenating in some way the <place name 1> value with any and all subordinate <alternate place name> values. You could actually take this a step farther and add a 3 TEXT <description> to the above construct to add some content to the popup.


2) If the display value comes from the hierarchy of the GM module location database then I would advocate a new column to be added to the database title "Description" which could hold all aka place values and potentially any text that the user would want to appear in the GM map popup. This solution would have no effect on the GEDCOM so a migration would only effect the underlying GM module location database, the second PLAC tag would not need to be stripped out when the GEDCOM is exported, since it is not valid.

1. Point Overlap already exists; it will not be caused by either of these suggestions. A possible solution for point overlap has already been posted in another RFE.

2. A plan or tool for migration to another design or system may be a good thing, but its absence doesn’t prevent this. How can you create a plan or tool to migrate to something that doesn’t exist?

Implementing my idea will NOT make webtrees perfect. But two worthwhile questions are:

Will it make webtrees better?
Is it more work than the benefit is worth?

It’s a request (suggestion) for a new feature, not a request for a redesign of the entire project.

Fine, you win, I'm DONE....

There is a database (with a webservice) available, which shows for a place the history of the place names and the hierarchical organisation, this place belongs to: GOV (Genealogisches Ortsverzeichnis), see wiki-de.genealogy.net/GOV in German or test it and search for places in English (or other supported languages): gov.genealogy.net/search/index/select?lang=en

Inside this database there are many places in Germany, former "german" countries, but in the meantime there are locations in England and many other countries, too. And it is "open", so you can edit the data or add new places in this database.

Therefore I decided to store in GEDCOM and webtrees only the actual place names, not the historical names. And I just started to develop a GOV module for webtrees 1.5 to show me all the historical data using the GOV webservice. I started with code from the google maps module, but finally I have rewritten a lot (after many years without programming experience), because there was too much "spaghetti" code inside the "old" Google Maps module. Still some things to be done, but it is on the way (don't use the gov.zip enclosed in productive systems, it is pre-alpha! and if you like to play with, you have to enter the GOV ids inside the GEDCOM using the _GOV tag or to enter it direct into the new SQL gov table).

Any comments, criticism and suggestions are more than welcome!

Hermann

Hermann, tried to test your GOV Module, but wasn't able to enable it in the admin module. Apparently I am missing something. Could you give me a hint?
Regards, Robert


EDIT: Meanwhile I found the error...the directory has to be "gov" not "Gov" or "GOV"

hello webtree community,
I just registered to take part in this discussion. I am working in the German "Gedcom-L", where we clarify the import & export problems with GEDCOM. I would like to point to the PLAC part of the results: wiki-de.genealogy.net/GEDCOM/PLAC-Tag
I have written a genealogical program using PHP, and in this program I implemented an online communication to the GOV System. So the user can search in this system directly within the genealogical program, and he can draw data from GOV simply by clicking on the place he wants to add to his own data base.
To do this I have implemented level 0 records for places ( 0 <XREF> _LOC ), as it was recommended by Gedcom-L. Import /export of place records to GEDCOM are working. Now I am programming a module to enable the user to choose by option, whether he wants to show in his reports the historical or the nowadays place name in his reports, and to choose the language. The data are provided by GOV, stored locally, and used to represent the place as the user has chosen. Another part will enable different options when exporting to GEDCOM, including historical / nowadays administration levels.
As webtrees and my program have the same programming language there may be chances to cooperate?!
Regards, Albert

Hi Albert,

I decided not go in my new gov webtrees module too far from the way webtrees is using places today, i.e. using the same logic which is used by the long existing google maps module in webtrees and not to use level 0 records for places. So storing the GOV id for a place in a database table and not inside the gedcom data. Has advantages and disadvantages, but a webtrees administrator is already familiar with this behavior. So my idea is:
1. as an admin: import all location data from your tree
2. select every location, search the GOV database using the GOV webservice, select the right GOV id for this place and store it in the database table
3. as an alternative you can use the _GOV tag inside your gedcom data as specified by the Gedcom-L group

As an user you will see on a new tab a table with all the locations which are relevant for a persons events. Depending on the language of the user and the date of an event you will see the most appropriate place name for this event. And you will find a link direct to GOV.

Programming is still not finished, but an alpha version is available. Up to now I don't have any idea how to present the GOV data in graphical form, and I'm sure that you will have many good ideas how to use the mighty GOV database, so cooperation is more than welcome!

best regards
Hermann

Hello together,

I read the previous replies with interest. I am also interested in an intelligent management of places in webtrees. As we all know, the 15 years old GEDCOM-standard do not support places in an useable way. There is only on text field with a pseudo structure for administrative hierarchies available.

In the GEDCOM-L list, as mentioned by Albert, a GEDCOM-conform solution for a variable place management is described - based on Level 0 records.

wiki-de.genealogy.net/GEDCOM/PLAC-Tag wrote: 0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M}
2 DATE <DATE_VALUE> {0:1}
2 _NAMC <PLACE_NAME_ADDITION> {0:1}
2 ABBR <ABBREVIATION_OF_NAME> {0:M}
3 TYPE <TYPE_OF_ABBREVIATION> {0:1}
2 LANG <LANGUAGE_ID> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 TYPE <TYPE_OF_LOCATION> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _FPOST <FOKO_POSTCODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
1 _POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _GOV <GOV_IDENTIFIER> {0:1}
1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> {0:1}
1 _FCTRY <FOKO_STATE_IDENTIFIER> {0:1}
1 MAP {0:1}
2 LATI <PLACE_LATITUDE> {1:1}
2 LONG <PLACE_LONGITUDE> {1:1}
1 _MAIDENHEAD <MAIDENHEAD_LOCATOR> {0:1}
1 EVEN [<EVENT_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {1:1}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _DMGD <DEMOGRAPHICAL_DATA> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1
1 _AIDN <ADMINISTRATIVE_IDENTIFIER> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> {1:1}
1 <<MULTIMEDIA_LINK>> {0:M}
1 <<NOTE_STRUCTURE>> {0:M}
1 <<SOURCE_CITATION>> {0:M}
1 <<CHANGE_DATE>> {0:1}

<HIERARCHICAL_RELATIONSHIP>:= [POLI|RELI|GEOG|CULT]

Based on this structure it is possible to maintain
- former names
- current and former hierarchies (administrative, law, church, etc.)
- several properties of a place or a hierarchical level (postal code, town-code, etc.)
- geographical location of the place (coordinates or a position on a map)

All these data are available in the GOV database. As Albert and Hermann wrote, there are existing php-modules to use the GOV web-services.
In GOV nearly 1 million entries for places are available (e.g. 350,0000 for USA, 150,000 for Germany, Austria, Poland, France, Spain, Sweden, Norway, ...). From my point of view the advantages of GOV compared to other databases are the different histories and names of the same location in dependence of hierarchy or time.

Are there any other users interested in such a solution? Is such a development in the scope of our developers?

Best regards
Peter

I've read this thread with interest as I too struggle with current vs historical place names. The "caveat" I always face is WHEN? When did the event occur so I know which place to use. My source is the GeoNames website then an Internet search if necessary to find when the change occurred. It gets harder when there are multiple names and I'm not certain which to use.