Re: [Gramps-devel] locations in 4.1

[Enno B. <enn...@gm...>]

John,
> You can read the full discussion of how GedcomX got there in 
> https://github.com/FamilySearch/gedcomx/pull/79
Nice reading. I stopped reading most of the discussions, when I found 
that things were going very slow on the persona side, and no steps were 
made regarding a practical set of citation elements.
> The executive summary is that we decided that for interchange purposes 
> it made more sense to flatten the structure into a comma-delimited 
> string rather than to enforce a particular hierarchical model on 
> client applications.
I fully agree with that, considering the problems that I already have 
with place fields in Gramps 3.4. I would love the situation to be 
otherwise, but reality as I see it is that it is impossible to enforce 
such a model indeed, for reasons that I already expressed in my message 
to Jerome.
> Apps which use a hierarchical model are expected to 
> serialize/deserialize the string from/into their model. No "place 
> authority" is specified for helping to disambiguate the string, but 
> clients are encouraged to use one, and FamilySearch provides one for 
> its users.
Right. I know the ones used by FamilySearch, Geni, and WeRelate, and 
like the practical approach taken by Dallan Quass. I see a problem in 
Gramps however, which already existed before 4.1, and that is that we 
have hybrid model now, where one can see the title as a serialized 
version of the location fields, while both can be edited, creating a 
huge maintenance problem for me. I now avoid that by ignoring all 
location fields, but would prefer a flexible hierarchy that translates 
to serialized strings in displays, reports, and GEDCOM files 
automatically. Problem with that however is that serializing is easy, 
even multi-lingual when I want to upload to US sites, but deserializing 
is not, because a compiled string has to type information.
> You'll see toward the end of the discussion that the Secret Force 
> (whom I believe to be the FS FamilyTree dev team) directed that the 
> two classes PlaceDescription and Place be flattened into a single 
> class, but that's immaterial to the serialisation of the place hierarchy.
You mean the additional feedback thomast73 refers to, right? I just 
found a similar thing on the FSDN list, where members noticed that one 
can not store multiple vital events anymore. Very enlightening.

regards,

Enno