> Here too, but there are too many levels for Dutch to understand, so I now see Province and Provincie, and I don't plan to do anything about that.
I suppose that nl.po uses something like:
You can also translate now, by:
Country: Country (Gedcom)
True, it is cosmetic, even on gedcom export, but it can explain the history of this level/type into current gramps' place hierachy handling.
> Another way would be to choose the city type, because that works for most locations, but that still is a wild guess.
Not certain that all places have a city ...
All places have/had a country (or sometimes/often more than one).
What about a simple event like emigration to the USA ...
or Nouvelle-France, New-England, New-Orleans !
What will be the city? Otherwise, "city" is maybe not the
right level for a simple farm?
Anyway, I suppose it is possible to move to "Unknown" or set a default type, but it looks like minor because user can fix the data by itself!
About internal places database, it is a little bit funny to see editors having hardcoded tables, now to have to rebuild them because there will be a change on current place hierarchy (eg, in France from 1960 -> to 2015).
To maintain a places DB (at least for France with around 37 000 cities!) is not something we can do just for fun ... In the past, I played with some open data (gramps, french gov.), but it is clear that most editors promote their own data set, via a wiki or whatever "private collaborative" hosting!
if someone needs a job! ;)
Le mar. 17 juin 2014 at 17:02, Enno Borgsteede <email@example.com> a écrit :
It looks like
that we are few to test and play with master/gramps41,
before a release...
Here too, but there are too many levels for Dutch to understand, so
I now see Province and Provincie, and I don't plan to do anything
Some weeks ago, I got problem with
translation strings around labels/words for place levels. It
takes some days, but I think that now it looks better, under
Well, as far as I see, GEDCOM doesn't prescribe anything, because
the PLAC tag as used in events is followed by a string that can
contain anything. Putting Amsterdam, Noord-Holland, Nederland there,
is just a convention, which I don't follow, because it is not
understood by American sites.
Sure, old gedcom model is also a problem
because it is based on US levels. eg, no county or state in
France (maybe no state everyelse than in the USA?).
The levels that you are referring too, which are in the ADDR
structures, are rare, because they are not used by events, which use
the PLAC tag instead.
Right, see above.
Since many versions, my locale used a
global translation matching county or state (Belgium,
Switzerland, Canada, Fance, etc ...) and since while I do
not trust gedcom specification for properly handling place
Yes, and for both title and source, this is a nuisance, because
composed place titles and citations are language dependent. I mean
that, where I might use
Like for Source, maybe the title (place or
source) is the only one inherited gedcom field which is
consistent according to all possible declinaison of gedcom
Amsterdam, Noord-Holland, Nederland
Netherlands, Noord-Holland, Amsterdam
in the catalog, and likes to normalize it to
in their on-line tree. And other sites like Ancestry and
WeRelate.org have yet another title for this.
For one of my German ancestors, the FS normalized place of birth is
Spenge, Spenge, Herford, Nordrhein-Westfalen, Germany
where their catalog says
Germany, Preußen, Westfalen, Spenge
This catalog is quite weird, because this is not a true hierarchy.
Germany and Prussia are mutually exclusive, and should therefore not
be in the same string. For my French ancestor, I can however live
with the FS normalized Montignac-le-Coq, Charente, Poitou-Charentes,
When you exchange data with the FS tree, via Ancestral Quest, or
RootsMagic, or whatever you like, you will encounter the normalized
names, not the catalog, so the problem is not that big, but IMO a
hierarchy will remain hard to use until all levels can be translated
I think so, yes, because the string in PLAC is undefined. Another
way would be to choose the city type, because that works for most
locations, but that still is a wild guess.
To have country as top level is maybe the
less inconsistent level when importing data from any gedcom
file? Agreed, to move the "unknown" when code does not know,
is maybe more right.
Indeed. From what I've seen, and Nick told, Gramps will use a
hierarchy when 3.4 location fields are filled, but if they are
empty, no hierarchy is used, just like in GEDCOM import. Auto
completion can be done with the tool that we already have, but that
tool uses a built-in table, which is hard to maintain. Using a web
service for this might be better, and such services exist, but I
have no idea how to address such a service from Gramps.
Note, it seems that gramps will create new
If something is not properly set, then we
can edit, merge, select or remove data, like for every
gramps objects. Locations were never filled after a gedcom
import, right? If so, maybe import and gedcom with this
autocompletion looks more complete than before!!! even, not
matching the expected level type... Gramps is maybe not
ready for a semantic support after importing a file format
without at least  a consistent way for handling semantic
Note that the GedcomX PlaceDescription type has no hierarchy like
Gramps, and some of the web services that I know, but is just a list
of names that can use different languages. The latter is nice, but
may also become quite a mess, I think. FamilySearch probably chose
this, because it is compatible with the normalized places that they
already have, and can be extended with localized normalized names,
but it is not very compatible with what we have now, because in
their system, there are no types. You can recognize levels in a
normalized string, but you don't really know what type these levels
One can say that for places, this is not much of a problem, because
levels are easier to recognize than fields in a complex citation,
where the language dependent part is much worse, because in a
formatted citation it is not just country names that need
translation, but also words like "accessed", "page", etc.