locations in 4.1

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

locations in 4.1

enno
Devs,
 
On testing Josip’s AIO, I found that most of the locations in my 3.4 database were converted to country type. Half a dozen are city, two dozen are streets now. In reality however, most are cities or villages. What can I do about that.
 
Also, when editing a location, I see that the title is there, but the name is empty, and on save, an error appears saying that the name can’t be empty. Would be much nicer if there is a name, same as title, to start with.
 
I tried the location tool, and that helps a bit for locations that are known by that, but since that number is quite limited, it doesn’t do much on this side of the ocean.
 
May I suggest:
1. Setting all types to unknown,
2. Setting name equal to title?
 
And to apply this before public release?
 
regards,
 
Enno
 

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

Nick Hall
On 16/06/14 13:57, Enno Borgsteede wrote:

> On testing Josip’s AIO, I found that most of the locations in my 3.4
> database were converted to country type. Half a dozen are city, two
> dozen are streets now. In reality however, most are cities or
> villages. What can I do about that.
> Also, when editing a location, I see that the title is there, but the
> name is empty, and on save, an error appears saying that the name
> can’t be empty. Would be much nicer if there is a name, same as title,
> to start with.
> I tried the location tool, and that helps a bit for locations that are
> known by that, but since that number is quite limited, it doesn’t do
> much on this side of the ocean.
> May I suggest:
> 1. Setting all types to unknown,
> 2. Setting name equal to title?
> And to apply this before public release?

The name and type are populated from the main location. This may create
several place objects.

Each field in the main location corresponds to a place type. You should
only get an empty name with an "Unknown" location if the main location
is completely empty.

You should copy part of the title into the name field and set an
appropriate type. Next choose a parent place. The title is generated
automatically from the names in the place hierarchy.

Nick.


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
Nick,
> The name and type are populated from the main location. This may create
> several place objects.
>
> Each field in the main location corresponds to a place type. You should
> only get an empty name with an "Unknown" location if the main location
> is completely empty.
In the context of 3.4, or imported GEDCOM, I have no idea what a main
location is. What's that?
> You should copy part of the title into the name field and set an
> appropriate type. Next choose a parent place. The title is generated
> automatically from the names in the place hierarchy.
If I'm supposed to set a type, it would be nice if the default type is
set to unknown, so that I can keep track of the locations that I have
edited. In reality however, I see that 99 % of my locations are
countries, even 100 % when I import from GEDCOM. That's what I don't
understand.

Hierarchy is another issue, that is probably better handled by a tool,
so I won't comment on that now.

regards,

Enno


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

Nick Hall
On 16/06/14 21:33, Enno Borgsteede wrote:
>> Each field in the main location corresponds to a place type. You should
>> >only get an empty name with an "Unknown" location if the main location
>> >is completely empty.
> In the context of 3.4, or imported GEDCOM, I have no idea what a main
> location is. What's that?

The main location is found in the "Location" tab in the place editor.

Each field in this tab, except for Postal Code and Phone Number, will
convert to a place in the place hierarchy.  The place type will
correspond to the field.

The Postal Code and Phone Number will be stored in the new Code field.


>> >You should copy part of the title into the name field and set an
>> >appropriate type. Next choose a parent place. The title is generated
>> >automatically from the names in the place hierarchy.
> If I'm supposed to set a type, it would be nice if the default type is
> set to unknown, so that I can keep track of the locations that I have
> edited. In reality however, I see that 99 % of my locations are
> countries, even 100 % when I import from GEDCOM. That's what I don't
> understand.

The place type of "Unknown" is only used when the import or database
upgrade is unable to determine a place type.  Users should not use
"Unknown", so I didn't want to use it as the default.

Nick.


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
Nick,
>>> Each field in the main location corresponds to a place type. You should only get an empty name with an "Unknown" location if the main locationis completely empty.
>> In the context of 3.4, or imported GEDCOM, I have no idea what a main
>> location is. What's that?
> The main location is found in the "Location" tab in the place editor.
>
> Each field in this tab, except for Postal Code and Phone Number, will
> convert to a place in the place hierarchy.  The place type will
> correspond to the field.
Thank you. This confirms my conclusion that something is wrong. Most of
the locations in my 3.4 database have an empty location tab, and should
therefore receive an empty name and unknown type after conversion. They
got the country type, however.
> The place type of "Unknown" is only used when the import or database
> upgrade is unable to determine a place type.  Users should not use
> "Unknown", so I didn't want to use it as the default.
See above. In 99 % of my locations, the location tab is empty, so the
upgrade is definitely unable to determine the type, just like you
described above. And in a GEDCOM file, every PLAC tag is by definition
unknown, since there is no ADDR structure there.

Since I see only country types after a GEDCOM import, I can only
conclude that your code does NOT match your words, so there is a real
inconsistency here.

regards,

Enno


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

jerome
It looks like that we are few to test and play with master/gramps41, before a release...

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 my locale.

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?).

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 levels!

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 files? [1]

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.

Note, it seems that gramps will create new place objects.
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 [2] a consistent way for handling semantic markers?

[1] http://bettergedcom.blogspot.fr/2011/01/further-place-names-in-gedcom-file.html
[2] https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#conclusion-place-reference


Le Mardi 17 juin 2014 1h50, Enno Borgsteede <[hidden email]> a écrit :


Nick,
>>> Each field in the main location corresponds to a place type. You should only get an empty name with an "Unknown" location if the main locationis completely empty.
>> In the context of 3.4, or imported GEDCOM, I have no idea what a main
>> location is. What's that?
> The main location is found in the "Location" tab in the place editor.
>
> Each field in this tab, except for Postal Code and Phone Number, will
> convert to a place in the place hierarchy.  The place type will
> correspond to the field.
Thank you. This confirms my conclusion that something is wrong. Most of
the locations in my 3.4 database have an empty location tab, and should
therefore receive an empty name and unknown type after conversion. They
got the country type, however.
> The place type of "Unknown" is only used when the import or database
> upgrade is unable to determine a place type.  Users should not use
> "Unknown", so I didn't want to use it as the default.
See above. In 99 % of my locations, the location tab is empty, so the
upgrade is definitely unable to determine the type, just like you
described above. And in a GEDCOM file, every PLAC tag is by definition
unknown, since there is no ADDR structure there.

Since I see only country types after a GEDCOM import, I can only
conclude that your code does NOT match your words, so there is a real
inconsistency here.

regards,


Enno


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
Hi Jerome,
It looks like that we are few to test and play with master/gramps41, before a release...
Yes indeed.
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 my locale.
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.
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?).
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.

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.
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 levels!
Right, see above.
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 files? [1]
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

    Amsterdam, Noord-Holland, Nederland

FamilySearch uses

    Netherlands, Noord-Holland, Amsterdam

in the catalog, and likes to normalize it to

    Amsterdam, Netherlands

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, France.

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 automatically.   
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.
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.
Note, it seems that gramps will create new place objects.
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 [2] a consistent way for handling semantic markers?
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 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 are.

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.

regards,

Enno



------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

John Ralls-2

On 17 Jun 2014, at 08:02, Enno Borgsteede <[hidden email]> wrote:

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 are.

You can read the full discussion of how GedcomX got there in https://github.com/FamilySearch/gedcomx/pull/79

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. 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. 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.

Regards,
John Ralls


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

jerome
In reply to this post by enno
Enno,

  > 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:

Country: Provincie
Province: ""

You can also translate now, by:

Country: Country (Gedcom)
Province: Provincie

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!

etc ...


if someone needs a job! ;)


regards,
Jérôme


Le mar. 17 juin 2014 at 17:02, Enno Borgsteede <[hidden email]> a écrit :
Hi Jerome,
It looks like that we are few to test and play with master/gramps41, before a release...
Yes indeed.
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 my locale.
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.
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?).
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.

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.
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 levels!
Right, see above.
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 files? [1]
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

    Amsterdam, Noord-Holland, Nederland

FamilySearch uses

    Netherlands, Noord-Holland, Amsterdam

in the catalog, and likes to normalize it to

    Amsterdam, Netherlands

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, France.

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 automatically.   
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.
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.
Note, it seems that gramps will create new place objects.
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 [2] a consistent way for handling semantic markers?
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 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 are.

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.

regards,

Enno



------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
Hi Jerome,

> I suppose that nl.po uses something like:
>
> Country: Provincie
> Province: ""
>
> You can also translate now, by:
>
> Country: Country (Gedcom)
> Province: Provincie
>
> True, it is cosmetic, even on gedcom export, but it can explain the
> history of this level/type into current gramps' place hierachy handling.
I checked the latest nl.po, but I really feel unable to translate it,
and that is because the Dutch language as I know it does not have enough
words to reflect all different location types. And if no one else can do
what I can't, this means that the Dutch version of Gramps 4.1 will not
be as user friendly as I like it to be. I am writing this with a view
from The Netherlands. The situation in Flanders may be different.

This problem already exists in 3.4, where in the official nl.po city is
translated to "dorp of stad", which means city or village, and locality
is translated to "plaats", which is the word that we normally use as a
generic term for dorp of stad. I am unable to come to an agreement with
fellow translators about this, so I simply maintain a separatist nl.po
for personal use now. My translation is most probably backed by a large
majority of the people of The Netherlands, but I see no other way to
implement it than by splitting nl.po into nl_NL.po and nl_BE.po, just
like that already exists for Portuguese for Portugal and Brazil. And the
problem with that is that, right now, I don't think we have enough
language specialists to maintain both. That may of course be an overly
pessimistic view.
>
>> > 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 ...
No, but I didn't mean it that way. What I mean is that in a practical
situation where genealogists record a location as a single word, that
location most often refers to a type at the city/town/village level.
That's the type of data that I find in records most of the time, even
though most records were and are kept at the municipal level. Anyway, I
think that in most single level locations recorded by genealogists, that
level is NOT of the country type.
> 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?
See above. I think most genealogists refer to locations like they use
them in mailing addresses. That means the name of a city/town/village in
the majority of cases, and exceptions for farms, that may be part of a
hamlet here, and part of a municipality, and may belong to a totally
different hierarchy in places like Canada.
> 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!
Well, that depends on the ease of fixing, right? When I can apply bulk
changes to locations, I can surely fix it myself, but if it's possible,
I prefer to have unknown now, and have a tool to change things.
> 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).
>
> http://genealogyblog.geneanet.org/index.php/post/2011/12/New:-Edit-your-Places-in-your-GeneaNet-Online-Family-Tree-GeneWeb.html
> http://blog.geneanet.org/index.php/post/2011/11/Comment-bien-saisir-vos-lieux-sur-GeneaNet.html
>
Hehe, yes. This is why I avoid hierarchies now, and apply a simple rule
to locations, which is that I can understand them myself, and don't
worry too much about others. It costs way less time to explain when
someone really wants to know what I mean, than to normalize everything
manually.

> 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!
>
> http://www.geonames.org/
> https://wiki.openstreetmap.org/wiki/MapQuest
> http://fr.geneawiki.com/index.php/Portail:Régionalisme 
> <http://fr.geneawiki.com/index.php/Portail:R%C3%A9gionalisme>
> https://github.com/DallanQ/Places/wiki/Database-download
> etc ...
>
Oh yes, I know, and given the way we all act, I see no other way. These
databases are very nice, but I am a little unhappy that in the French
geneawiki, Pays Basque is there, but Pays Bas is not ...
>
> PS: by looking at one blog, I saw:
> http://genealogyblog.geneanet.org/index.php/post/2014/03/Geneanet-Job-Offer:-Genealogical-Data-Manager.html
> if someone needs a job! ;)
>
Not me. I'm too sloppy for that, and not fluent speaking or writing
French. I can read it quite well, but that's all.

regards,

Enno


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

ACProctor
Re: hierarchies, I´ve been struggling with the different types for a while but I´m starting to make some serious progress here. Basically, the different types (e.g. geographical, administrative, local government, ecclesiastical, etc) don´t have to be exclusive. I´ve been "setting the scene" for this with my "related entities" blog post. I know it doesn´t help this thread much but I promise I will write it up soon - if for nothing else than a different point of view that might be interesting.
 
    Tony Proctor
 
on Jun 17, 2014, Enno Borgsteede <[hidden email]> wrote:

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
In reply to this post by John Ralls-2
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


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

derHeinzi
In reply to this post by enno

Hi Enno,

great statement you made here from my point of view as a German. What you said is valid for Germany as well.

Another point I'm struggling with,even since earlier versions of Gramps, is the mixing of "governmental" and "religious" place descriptions. These should be handled separately IMHO. Even though the state boundaries may be the same for Catholic and Protestant administrative boundaries this is not true for the smaller entities. So these are needed to really be held in parallel. A burial should e.g.  be able to have 2 (or even more?) place entries. One for the "civil" place hierarchy Country, State, ...?, Locality and another one for a religious hierarchy Country, Diocese, ...?, Parish.
I don't even know if the administrative boundaries are the same for Catholic and Protestant administration. But the graveyards of the Catholic Parish and the Protestant Parish may be close together and a "Locality" may have more than one of each.
And who knows how other religions in other places of the world are organized?

regards,
Heinz

On Tue, 17 Jun 2014 22:36:54 +0200, Enno Borgsteede <[hidden email]> wrote:

> Hi Jerome,
>> I suppose that nl.po uses something like:
>>
>> Country: Provincie
>> Province: ""
>>
>> You can also translate now, by:
>>
>> Country: Country (Gedcom)
>> Province: Provincie
>>
>> True, it is cosmetic, even on gedcom export, but it can explain the
>> history of this level/type into current gramps' place hierachy handling.
> I checked the latest nl.po, but I really feel unable to translate it,
> and that is because the Dutch language as I know it does not have enough
> words to reflect all different location types. And if no one else can do
> what I can't, this means that the Dutch version of Gramps 4.1 will not
> be as user friendly as I like it to be. I am writing this with a view
> from The Netherlands. The situation in Flanders may be different.
>
> This problem already exists in 3.4, where in the official nl.po city is
> translated to "dorp of stad", which means city or village, and locality
> is translated to "plaats", which is the word that we normally use as a
> generic term for dorp of stad. I am unable to come to an agreement with
> fellow translators about this, so I simply maintain a separatist nl.po
> for personal use now. My translation is most probably backed by a large
> majority of the people of The Netherlands, but I see no other way to
> implement it than by splitting nl.po into nl_NL.po and nl_BE.po, just
> like that already exists for Portuguese for Portugal and Brazil. And the
> problem with that is that, right now, I don't think we have enough
> language specialists to maintain both. That may of course be an overly
> pessimistic view.
>>
>>> > 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 ...
> No, but I didn't mean it that way. What I mean is that in a practical
> situation where genealogists record a location as a single word, that
> location most often refers to a type at the city/town/village level.
> That's the type of data that I find in records most of the time, even
> though most records were and are kept at the municipal level. Anyway, I
> think that in most single level locations recorded by genealogists, that
> level is NOT of the country type.
>> 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?
> See above. I think most genealogists refer to locations like they use
> them in mailing addresses. That means the name of a city/town/village in
> the majority of cases, and exceptions for farms, that may be part of a
> hamlet here, and part of a municipality, and may belong to a totally
> different hierarchy in places like Canada.
>> 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!
> Well, that depends on the ease of fixing, right? When I can apply bulk
> changes to locations, I can surely fix it myself, but if it's possible,
> I prefer to have unknown now, and have a tool to change things.
>> 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).
>>
>> http://genealogyblog.geneanet.org/index.php/post/2011/12/New:-Edit-your-Places-in-your-GeneaNet-Online-Family-Tree-GeneWeb.html
>> http://blog.geneanet.org/index.php/post/2011/11/Comment-bien-saisir-vos-lieux-sur-GeneaNet.html
>>
> Hehe, yes. This is why I avoid hierarchies now, and apply a simple rule
> to locations, which is that I can understand them myself, and don't
> worry too much about others. It costs way less time to explain when
> someone really wants to know what I mean, than to normalize everything
> manually.
>> 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!
>>
>> http://www.geonames.org/
>> https://wiki.openstreetmap.org/wiki/MapQuest
>> http://fr.geneawiki.com/index.php/Portail:Régionalisme
>> <http://fr.geneawiki.com/index.php/Portail:R%C3%A9gionalisme>
>> https://github.com/DallanQ/Places/wiki/Database-download
>> etc ...
>>
> Oh yes, I know, and given the way we all act, I see no other way. These
> databases are very nice, but I am a little unhappy that in the French
> geneawiki, Pays Basque is there, but Pays Bas is not ...
>>
>> PS: by looking at one blog, I saw:
>> http://genealogyblog.geneanet.org/index.php/post/2014/03/Geneanet-Job-Offer:-Genealogical-Data-Manager.html
>> if someone needs a job! ;)
>>
> Not me. I'm too sloppy for that, and not fluent speaking or writing
> French. I can read it quite well, but that's all.
>
> regards,
>
> Enno
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

Nick Hall
On 17/06/14 23:00, Heinz Brinker wrote:
> Another point I'm struggling with,even since earlier versions of Gramps, is the mixing of "governmental" and "religious" place descriptions. These should be handled separately IMHO. Even though the state boundaries may be the same for Catholic and Protestant administrative boundaries this is not true for the smaller entities. So these are needed to really be held in parallel. A burial should e.g.  be able to have 2 (or even more?) place entries. One for the "civil" place hierarchy Country, State, ...?, Locality and another one for a religious hierarchy Country, Diocese, ...?, Parish.
> I don't even know if the administrative boundaries are the same for Catholic and Protestant administration. But the graveyards of the Catholic Parish and the Protestant Parish may be close together and a "Locality" may have more than one of each.
> And who knows how other religions in other places of the world are organized?
>

In v4.1, it is possible to define multiple regions in which a place may
be located.  So a graveyard could be defined to be within a parish and
also within a village, for example.  The links between places and their
parent places can have an optional date range associated with them.  
Places can also have alternative names.

This could lead to quite complex hierarchies of places.  However, it is
important to note that users are not forced to use all the features
provided.  It will be interesting to see what feedback we get.


Nick.


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

enno
In reply to this post by derHeinzi
Hallo Heinz,
> I don't even know if the administrative boundaries are the same for Catholic and Protestant administration.
I know, and the answer is not, for both of our countries. See

http://wiki-de.genealogy.net/Portal:Regionale_Forschung

for Germany. It is not that important for research here, because church
books are stored in civilian archives, but it is very relevant when you
want to find a record for a German relative.

regards,

Enno


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

Helge.Herz-2
Hi all,

just to show one example about the complex and time related hierarchy of
one church in one German town only (a quit simple case) [1].
You may search the the system for further place relation ships: [2].
In [2] you may ask e.g. for "Breslau" to find a lot of churches
(catholic or protestant) in the same town...

I'm for myself focused on pure genealogy. So I prevent to document all
these detailed time depending information in my database.
- Helge

[1] http://gov.genealogy.net/item/show/object_160817
[2] http://gov.genealogy.net/search/index
Am 18.06.2014 00:46, schrieb Enno Borgsteede:

> Hallo Heinz,
>> I don't even know if the administrative boundaries are the same for Catholic and Protestant administration.
> I know, and the answer is not, for both of our countries. See
>
> http://wiki-de.genealogy.net/Portal:Regionale_Forschung
>
> for Germany. It is not that important for research here, because church
> books are stored in civilian archives, but it is very relevant when you
> want to find a record for a German relative.
>
> regards,
>
> Enno
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: locations in 4.1

jerome
In reply to this post by enno
Hi Enno,

As a wiki, we can guess that some urls and references are sometimes broken or missing...

http://fr.geneawiki.com/index.php/Pays-Bas

They started a country page, created a category and related pages!


Maybe need to also look at:


regards,
Jérôme

Le mar. 17 juin 2014 at 22:36, Enno Borgsteede <[hidden email]> a écrit:
Oh yes, I know, and given the way we all act, I see no other way. These databases are very nice, but I am a little unhappy that in the French geneawiki, Pays Basque is there, but Pays Bas is not ...
regards, Enno

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel