Please do NOT post requests for help here. Use the Help forum for that.

TOPIC: logical behavior for places

logical behavior for places 1 month 2 weeks ago #1

  • GunnarO
  • GunnarO's Avatar
  • Offline
  • New
  • Posts: 22
I'm unsure, till now i used, the name, destrict etc., state for the place at the time of a event.
But in most lists i find only the actual informations referenced.

So whats the logic behind, how was it thought ?
The german wiki-pages doesn't help much, but since there pointing to GoogleMaps i asume the actual names and relations should be used?


i know:
- areas can be collected by , HIGHER , HIGHER, HIGHEST order element
--> Collections are viewable by hierarchy
- With GOV binding most should be shown both (after binding)

(
In europe many borders changed through the past centuries, especially around the world wars.
Limburg, was one area, was part of german federal, on off on off, now Limburg are part of three states. same on eastside prussia, polski, german, russia, ... even often changed names.
)
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #2

  • bertkoor
  • bertkoor's Avatar
  • Offline
  • Gold
  • Greetings from Utrecht, Holland
  • Posts: 1727
Places are very complex things. As you already noted, their names, spelling and hierarchy often changes over time. This is a true problem in genealogy, and there's not one approach that fits all use cases.

To complicate it even further, in Gedcom (the definition of the data structures we use) places are not first class citizens. They are rather free format. Essentially you may do whatever you want or what seems to you what's right.

It would be nice if places were true objects with events that describe dates at which their names or hierarchy change. But we don't have that.

You mention GOV and GoogleMaps. I don't use them, so I cannot comment on that.

The approach I currently use, is in principle to use the current division of places. This gives the reader a familiarity with the current place hierarchy. So for example I note Paris as "Paris, Paris (75), Île-de-France, FR", even when the event was long before the departement existed and got number 75.

in case ownership or names changed, or another name was used in my language, I tend to notate that as per this example: Koningsbergen, Königsberg (Preußen), Kaliningrad, Russia.

Another thing I have done in the past is to use Shared Notes that explain the situation.

Whatever you decide to do, try to make it clear to the reader you are aware of changes in hierarchy or name, but at the same time point to the current situation. It's hard...
stamboom.BertKoor.nl runs on webtrees v1.7.13
Last Edit: 1 month 2 weeks ago by bertkoor.
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #3

  • GunnarO
  • GunnarO's Avatar
  • Offline
  • New
  • Posts: 22
That would be a strange behavior in my cause, since Prussia, German Reich would be under 3. Rp Poland. So the Hierarchy of places would fuck up ?!
the GOV extension uses the GOV-Data and can show old, today or both. Also in set language if avaible. (for me in german)

. > > Picture of it < <

it also provides longitude / latidude for actual Map Services so name isn't as important anymore.
As i understood the source it generates a table with entered entries vom Places and the id of GOV, searched for only one time.


But yeah, you're right, an place with events, to document changes, would be nice.

Since it's mixed in my database i must decide which form will keep. With update placename it is easy to switch onetime.
That's why i'm ask, maybe theres a better logic i doesn't have realised.
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #4

  • fisharebest
  • fisharebest's Avatar
  • Online
  • Administrator
  • Posts: 12272
In genealogy, we have two types of data: "evidence" and "conclusion".

GEDCOM is designed around "conclusions".

It was designed to allow genealogists to submit the conclusions of their research to the headquarters of the LDS church.

The SOUR fields obviously contain evidence - but other fields such as DATE/PLAC are conclusions.

Evidence is the information you find. So sources will always contain historic place names.

Conclusions are how you display the results of your research. IMHO, this should be in a standard format. This means two things:

* using the current place names.
* using just one language (e.g. Deutschland versus Germany).

There is one exception. If you cannot identify the current place name...

For example, if I have an event "birth: 1970, Czechoslovakia", and I do not know the city, then I must use "Czechoslovakia" instead of "Czech Republic" or "Slovakia".
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #5

  • ddrury
  • ddrury's Avatar
  • Offline
  • Senior
  • Posts: 268
Back in the mists of time, I recall a discussion in these forums about webtrees adhering strictly to the Gedcom spec, after all what goes on in the black box that is webtrees is irrelevant as long as it can import and export a valid Gedcom file.

Locations (I use location rather than place deliberately) seem a valid case that maybe justifies deviating from the spec. A location has unchanging map co-ordinates regardless of it being named New Amsterdam or New York.

I also appreciate that exporting locations that have more than one name would need some thought but with someone of Greg's abilities I don't think it would be unsurmountable.

Discuss...
--
Dave

Local: Win 10 Pro, Nginx: 1.17.4, PHP: 7.3.11 & 7.4.1, MariaDB: 5.5.5-10.4.8 all 64bit
Production: linux 2.6.32.21-grsec #5 SMP, Apache 2.2, PHP 5.7.13, 10.3.18-MariaDB
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #6

  • fisharebest
  • fisharebest's Avatar
  • Online
  • Administrator
  • Posts: 12272
In my tree, I have the place England.
You probably have it too.

It's is the *same* England. It has the same name, same co-ordiantes, same history, same population, same flag, same everything.

So why do we want to have this same data added to *every* GEDCOM file?

Surely it is better to have one global master database to which everyone refers?

This way, if something gets updated (e.g. a new flag, or a change of name, additional information, etc.), then we don't need to update a million GEDCOM files.

I think having a resource that everyone can share is a good thing.
But I am not convinced that everyone should have to maintain their own, incomplete, outdated piece of it.

> A location has unchanging map co-ordinates regardless of it being named New Amsterdam or New York.

...except, of course when they change (en.wikipedia.org/wiki/Kiruna#Moving_the_town)

...or disappear and then reappear with different borders (Germany -> GDR+DDR -> Germany).

etc.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #7

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Gold
  • Posts: 1558
As a historian, but also a realist, I have the same dilemma running thru my head all the time with “place”.

I like to be historically accurate, and teach readers about history and in particular the history of the place and/or time. But I also realize that 99.9% of the readers of my family history (this would be apposed to readers of articles I write about Viking history) do not really care about the old spelling of a place, or that the place was part of various countries over time and that you may not find the place today based on the historical name.

Rather, they want to be able to do is to find it on a map, and say “great grandpa came from Norway”, or that we are part Hungarian because a g-g-great grandma came from there. They are not interested in knowing that they are more German than Hungarian because their forefathers a few generation farther back were from Germany. Later they may ask “how is it possible that they spoke only German if they came from Hungary?” My notes associated with the person and sources, help to explain this.

Therefore I use modern place names in webtrees so than maps can be used to locate the place, with notes and sources that point individuals wanting more information to ask questions.

This is my solution, you may have a different audience or different reasons to generate a GEDCOM.
Ken
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #8

  • GunnarO
  • GunnarO's Avatar
  • Offline
  • New
  • Posts: 22
oh i didn't want break an discussion forth, i just wanted to outsource my considerations.

by the topic, the gov database makes exactly what you describe. it delivers the old and the new.

Since Amsterdam become an example

all links delivers with one id the exactly answer with more informations: long/lat, different languages (incomplete), different states ( by time) , etc.
As fisharebest says, wouldn't it be better to extend one place that all users use? So why not using an existing project, instead of reinventing the wheel once again?


btw. GDR is DDR ;)
so it would be Germany --> BRD, GDR, East-Germany (under polish leadership), Samland (under russia) --> Germany , part of Polska, Part of Russia ... but back to topic.
The administrator has disabled public write access.
Do you need a web hosting solution for your webtrees site?
If you prefer a host that specialises in webtrees, the following page lists some suppliers able to provide one for you: 

logical behavior for places 1 month 2 weeks ago #9

  • ddrury
  • ddrury's Avatar
  • Offline
  • Senior
  • Posts: 268
@fisharebest
Surely it is better to have one global master database to which everyone refers?

Agreed, but this isn't contrary to my original blackbox point, whether the data is stored in each database or one central database, webtrees will still have to manage how it's input/retrieved, displayed and output on creation of a Gedcom.
...except, of course when they change (en.wikipedia.org/wiki/Kiruna#Moving_the_town)
...or disappear and then reappear with different borders (Germany -> GDR+DDR -> Germany).

Accepted, but in the grand scheme of things, these I suspect are in the minority (albeit maybe a large minority - I don't know) and it wouldn't be that difficult to handle in some form or other, even if as suggested more than once for the current situation to use a shared note.
--
Dave

Local: Win 10 Pro, Nginx: 1.17.4, PHP: 7.3.11 & 7.4.1, MariaDB: 5.5.5-10.4.8 all 64bit
Production: linux 2.6.32.21-grsec #5 SMP, Apache 2.2, PHP 5.7.13, 10.3.18-MariaDB
The administrator has disabled public write access.

logical behavior for places 1 month 2 weeks ago #10

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Gold
  • Posts: 1558
The German based “gov” site has some advantages, however!

I don’t like that it uses a non-standard tag to get at the data. These tags will be lost in GEDCOM transport.
I don’t like having to enter a place and a location.
I don’t like that it may not support my location specific uses for grave locations, homes, farms, language and spelling differences.
Ken
The administrator has disabled public write access.

logical behavior for places 1 month 1 week ago #11

  • rockley
  • rockley's Avatar
  • Offline
  • New
  • Posts: 6
For the places, it would be good to have one database.

Download the places from gov or open sources, like geonames. Import the file into Control panel/Geographic data.

But there is a little disadvantage of it, when you enter the location, it only suggests active places(which has been entered before), not all the places in Geographic data.
This will causes some duplication or mistakes by different editors.
EX: "New York, United States" versus "New York City, United States" versus "New York, US".

If it suggests all the places in the data, that will be unity.
Last Edit: 1 month 1 week ago by rockley.
The administrator has disabled public write access.

logical behavior for places 1 month 1 week ago #12

  • xmlf
  • xmlf's Avatar
  • Online
  • New
  • Posts: 96
In China, entering place names is achieved through a multi-level linkage drop-down list. This ensures that the names are the same.
Wang Family Website of Suining County, China
https://www.snwsjz.com
A family tree website that is customized, more humanized and convenient for users.
The administrator has disabled public write access.

logical behavior for places 1 month 1 week ago #13

  • fisharebest
  • fisharebest's Avatar
  • Online
  • Administrator
  • Posts: 12272
> But there is a little disadvantage of it, when you enter the location, it only suggests active places(which has been entered before), not all the places in Geographic data.

When you enter place names, the "auto-complete" will suggest place names in the current tree.

It does not suggest places from other trees.

This is intentional.

Suppose you have two trees. Tree 1 is public. Tree 2 is private.

If the autocomplete for tree 1 included the place names from tree 2, then it would allow a user to identify all the places in the private tree2.
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net
The administrator has disabled public write access.

logical behavior for places 1 month 6 days ago #14

  • rockley
  • rockley's Avatar
  • Offline
  • New
  • Posts: 6
>This is intentional.
>Suppose you have two trees. Tree 1 is public. Tree 2 is private.

Got you. That is cool! Did not realize it, I only have one tree.

By the way, looks like "auto-complete" cell without yellow background right now in 2.0, I think that's a good feature can be inherited.
The administrator has disabled public write access.
Powered by Kunena Forum