GEPS 045 Place enhancements and Place types

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

GEPS 045 Place enhancements and Place types

prculley
I would appreciate comments and especially answers to the questions below.

Currently the GEPS code supports the 4.2.x-5.1.x Place types, as well as custom types from users or sources like the GOV database.  It does this by extending the original GrampsType concept for place types, storing customized data in the db metadata, and the class itself, and allowing modifications of that data in Preferences.

I've been told that is "the wrong approach".

The suggested approach is to make place type data "like tags", based on the TableObject (with a handle etc.).  The implication is that place types become db objects.

Another suggestion is to "Keep the place type management to one simple dialog. Typing some text in an entry field should be sufficient to create a new type in most cases."

I'd like to get a few questions answered so that I can make progress on this.

When a user wants to assign a place type, he currently uses a GUI widget that combines a drop-down selector with an Entry, so he can either select from a set of values, or enter a new value.  I think we should continue to use this, as it is familiar.
  • What should be in the selectable set of values?
  • For an existing db, I think we should present the values currently used, at least.  Agreed?
  • I also think we should see whatever appears for a new db. Agreed?
  • When I open a new db, what do we want to see?
    1. If we do this like tags, there would be nothing.
    2. The previous Gramps versions Place Types.
    3. A simplified set of standard types.
    4. A user configured set of types defined in Preferences or in some other tool.
    5. Some combination of the above.
  • If we have a simplified set of types, what should be used?
    • One proposal is to have: (Country, Region, Populated Place, Unpopulated Place, Building).  These match up to the default Groups and allow a user to just provide differentiation enough for Title generation.
  • When the user enters text manually, this can create a new place.  What are its characteristics?
    • A default value (Group:Populated place, Name in current language, color:default, Description:Custom, Visible:True)
    • We could additionally pop up an editor to allow setting the other place characteristics.
Place types do have additional characteristics:
  • Group (inherited from GrampsType with initial values of Country, Region, Populated Place, Unpopulated Place, Building).
  • Name in current language
  • Visibility (whether to show in place selector menu)
  • Marker Color (this may be deferred to future version)
  • Names in other languages (this may be deferred to future version)
  • Description (Original Gramps Place Type?, GOV_TYPE?, custom?)
  • Where do we want to edit these?
    • In Preferences
    • With another menu item similar to 'Organize Tags'
  • I assume we would want to add, edit and remove (remove only if not used). Agreed?

A note about the original place types and translations:  There is a proposal to drop support for previous pre-defined place types.  If this is done completely, all current trees would end up with English place types, since English is what is stored in the XML. 

  • If we chose to drop support for previous types, I propose that we retain the ability to translate to the current language, and do that on import or db upgrade.  That way previous types would appear in the tree in the current language.  Agree?

If/when we decide to support more than one language for names in the place types characteristics, I would expect that these would also get free (not configured by the user) translations to other languages.

Paul C.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
On 15/03/2020 19:19, Paul Culley wrote:

> I would appreciate comments and especially answers to the questions below.
>
> Currently the GEPS code supports the 4.2.x-5.1.x Place types, as well
> as custom types from users or sources like the GOV database.  It does
> this by extending the original GrampsType concept for place types,
> storing customized data in the db metadata, and the class itself, and
> allowing modifications of that data in Preferences.
>
> I've been told that is "the wrong approach".
>
Yes.  I feel that the approach taken in the GEPS is overly complicated. 
Feedback from the user consultation indicated that free-form text is all
that is required for place types.

I suggest the following:

1.  Create a new PlaceGroup type inheriting from GrampsType. This would
be a controlled set of place categories for use in place formatting. 
The groups could be:

* Region (e.g.  country, state, province, county)

* Settlement  (e.g. hamlet, village, town, city)

* Locality (an area within a settlement - e.g. borough, neighbourhood,
street)

* Building (domestic or institution)

* Unpopulated place (e.g. cemetery, battlefield)

These groups are not time dependent.  This functionality should be
sufficient for most users.

I see no problem adding this as an additional field even if we decide to
leave the PlaceType class unchanged.

2.  Make place types time-dependent.  This was a change requested by
users.  Each entry in the place type list should contain the following
fields:

* A PlaceType.

* A date range.

* A list of citations.

Again, I don't see a problem here.  We could even leave the PlaceType
class unchanged.

3.  Modify the PlaceType class.  The basic requirement here is to change
from a controlled set to free-form text.  However, there are other
fields that may be implemented now or in the future which we also have
to consider.

We may wish to store:

* A colour for use in the geography views.

* A PlaceGroup.

* An external ID.  (e.g. from the GOV database)

* User-defined translations.

* A list of countries that use the type.

This information should really be stored in its own table.  I am also
not suggesting implementing any of this immediately. Development in
small steps is better.  In fact, keeping the PlaceType class unchanged
might be sensible at this stage.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Fwd: GEPS 045 Place enhancements and Place types

prculley
1.  Create a new PlaceGroup type inheriting from GrampsType. This would
be a controlled set of place categories for use in place formatting. 
Already Agreed...
The groups could be:
* Region (e.g.  country, state, province, county)
A year ago we settled on Country and region (presumably to allow for easier Title formatting of Country vs. state)...
* Settlement  (e.g. hamlet, village, town, city)
I guess this would be another name for populated place

* Locality (an area within a settlement - e.g. borough, neighbourhood,
street)
New idea, but reasonable.

* Building (domestic or institution)

* Unpopulated place (e.g. cemetery, battlefield
Both already there...

2.  Make place types time-dependent.  This was a change requested by
users.  Each entry in the place type list should contain the following
fields:
* A PlaceType.
* A date range.
* A list of citations.
Again, I don't see a problem here.  We could even leave the PlaceType
class unchanged.
 The current PR already has this in place, but I am trying to reconcile this with the notion of using Tag like (TableObject) place types in the db.  As noted in the PR comment, I think if we do the TableObject derived Place Types, then we also have to have PlaceTypeRef objects to hold the Date/Citations.

3.  Modify the PlaceType class.  The basic requirement here is to change
from a controlled set to free-form text.  However, there are other
fields that may be implemented now or in the future which we also have
to consider.
We may wish to store:
* A colour for use in the geography views.
* A PlaceGroup.
* An external ID.  (e.g. from the GOV database)
* User-defined translations.
* A list of countries that use the type.
The current PR already has Group (to be replaced with PlaceGroup), and a way to store the external ID.
Adding Color is not difficult, just shifts the color data from the geography view to the Place Type and adds to the editor.
I have thought through the user translations and think I know how to do it for Gramps Views and editors, and the two reports that show place types.  But the interaction with legacy place types is less clear as mentioned in my earlier email.
The countries thing is not at all clear to me at the moment, mostly because I cannot figure out how to use it.  If used in a place type menu, would we force the user to enclose the place in the appropriate country before he could assign the place type?  What would it be good for other than the place type menu?

This information should really be stored in its own table. 
The current PR stores this sort of information in the PlaceType class itself while running, and copies it to metadata in the db/XML when Gramps closes or exports.   My understanding from comments last week is that you want this in a db object, based on TableObject.
I am also
not suggesting implementing any of this immediately. Development in
small steps is better.  In fact, keeping the PlaceType class unchanged
might be sensible at this stage.
I feel confused.  Do you want me to start coding for TableObject Place Types as you wanted last week, now, or not?

And finally, I notice that you did not actually answer any of my specific questions in my earlier email.

Paul C.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
On 17/03/2020 15:43, Paul Culley wrote:
* Region (e.g.  country, state, province, county)
A year ago we settled on Country and region (presumably to allow for easier Title formatting of Country vs. state)...

A country is just another administrative region, so it doesn't really need it's own group. 

There are a few reasons why I excluded country as a group:

* The group should be independent of time.  Conceptually, I see Prussia, for example, as a region.  At some points in it's history it has been a nation state and now it is a region in Germany.

* The word "country" has different meanings in the English speaking world.  It can mean a nation state or just a region with a cultural and historic identity.

* It isn't necessary.  Keep things simple.  From what I can remember, the GeoNames data records a nation state as ADM0 which is just a top-level region.

I'll add more comments in separate posts.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
In reply to this post by prculley
On 17/03/2020 15:43, Paul Culley wrote:
The current PR stores this sort of information in the PlaceType class itself while running, and copies it to metadata in the db/XML when Gramps closes or exports.   My understanding from comments last week is that you want this in a db object, based on TableObject.

There have been three options suggested:

1. Store the place type as free-form text.

This was suggested by John Ralls in the PR.  It also seems to meet all the requirements from the user consultation.

There are no pre-defined types and no configuration is needed.


2. Store the place type in a separate table.

This was my suggestion.  The place type would inherit from a TableObject and would be referenced from a PlaceTypeRef object.

There are no pre-defined types and simple configuration is needed for colours, group etc...

This is a flexible option that allows filtering without a full table scan.


3. Store the place type in metadata.

As in the current PR.  I have a few concerns, but perhaps they can be overcome.

The metadata table is the wrong place to store this information, but we could create another table.

The pre-defined types should be removed.  The visibility option just adds complexity.

The group mapping needs to be simplified.  A type should only belong to a single group.  I don't think that the bitmap implementation is necessary.


In general, the best designs are simple and will be easier for users to understand.  In this respect I'm even tempted by option 1.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

prculley
Some counter arguments:
1) free form text:  While I understand the apparent simplicity, I really think that new users would find an empty entry box a bit less intuitive than the current selector with some standard place types.  For current users, the need to enter by manually keying in the place type would be 'different', and more error prone.  I really think that taking away a Gramps 'feature' in the name of simplicity is not a good idea, especially since we are doing this whole place enhancements thing to add complexity for those users that want to have more complete/accurate place descriptions.

2) How we store the data internally seems like something we can eventually come to an agreement on, but should not much affect the user experience.  I prefer continuing to support the current 4.x.x+ place types as a predefined set, along with the ability to translate them.  This would also mean continued use of the ComboEntry as the user GUI element, with predefined and custom types in the drop down menu.  Adding the ability to define marker colors and group with some other editor is good.

3) I've already talked about predefined types. The visibility option in the current PR is there to deal with the potentially large number of place types in the ComboEntry.  If a user has a lot of European Places, and he uses GOV data, he will end up with a lot of place types.  Many of which he may never need to choose when entering manual places.  The ability to 'hide' some places from the menu was intended to simplify the Combo menu in this case.  I can accept the single group per type.

I originally had the place type data in db metadata because that is where we were storing custom place (and other) types in previous Gramps versions.  If making a special table is desirable, it can be done.  I do think it makes more sense to maintain the table data in the class during runtime, to avoid time expensive db reads of the table data.  If we used such a table, update during runtime when place types were added or changed would probably be a good idea.

And regarding 'Countries' as a place group;  in my personal use, I like the idea of abbreviating the country and state/province and skipping the anything between that (county etc.) and the bottom level ('populated place') for the charts place titles.  Since my data include some European places, and I often use GOV data, the top level of the hierarchy is usually 'European Union', which is grouped in the GOV data as part of the 'countries' group.  France, for instance, is also grouped as part of the 'countries' group.  So with the current PR, I would write a rule that says "show/abbreviate smallest of countries group, and show/abbreviate largest of 'regions' group", the smallest level being shown by default.  This works well for my data which includes US, Canada and EU places.  If we did not support a 'countries' group, but only a 'regions' group, I'm not sure how I would write this rule without using place specific exception rules.  Even then, we would need a way to say "show the 2nd and 3rd level of the regions group".

Paul C.

On Fri, Mar 20, 2020 at 4:27 PM Nick Hall via Gramps-devel <[hidden email]> wrote:
On 17/03/2020 15:43, Paul Culley wrote:
The current PR stores this sort of information in the PlaceType class itself while running, and copies it to metadata in the db/XML when Gramps closes or exports.   My understanding from comments last week is that you want this in a db object, based on TableObject.

There have been three options suggested:

1. Store the place type as free-form text.

This was suggested by John Ralls in the PR.  It also seems to meet all the requirements from the user consultation.

There are no pre-defined types and no configuration is needed.


2. Store the place type in a separate table.

This was my suggestion.  The place type would inherit from a TableObject and would be referenced from a PlaceTypeRef object.

There are no pre-defined types and simple configuration is needed for colours, group etc...

This is a flexible option that allows filtering without a full table scan.


3. Store the place type in metadata.

As in the current PR.  I have a few concerns, but perhaps they can be overcome.

The metadata table is the wrong place to store this information, but we could create another table.

The pre-defined types should be removed.  The visibility option just adds complexity.

The group mapping needs to be simplified.  A type should only belong to a single group.  I don't think that the bitmap implementation is necessary.


In general, the best designs are simple and will be easier for users to understand.  In this respect I'm even tempted by option 1.


Nick.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

enno

Hi Paul,

Some counter arguments:
1) free form text:  While I understand the apparent simplicity, I really think that new users would find an empty entry box a bit less intuitive than the current selector with some standard place types.  For current users, the need to enter by manually keying in the place type would be 'different', and more error prone.  I really think that taking away a Gramps 'feature' in the name of simplicity is not a good idea, especially since we are doing this whole place enhancements thing to add complexity for those users that want to have more complete/accurate place descriptions.
I agree. Predefined place types are helpful, as long as they fit in the user's mind, and are available for the proper locale.

2) How we store the data internally seems like something we can eventually come to an agreement on, but should not much affect the user experience.  I prefer continuing to support the current 4.x.x+ place types as a predefined set, along with the ability to translate them.  This would also mean continued use of the ComboEntry as the user GUI element, with predefined and custom types in the drop down menu.  Adding the ability to define marker colors and group with some other editor is good.
Makes sense. I have no interest in marker colors, but if the UI stays simple enough, I will not object.

3) I've already talked about predefined types. The visibility option in the current PR is there to deal with the potentially large number of place types in the ComboEntry.  If a user has a lot of European Places, and he uses GOV data, he will end up with a lot of place types.  Many of which he may never need to choose when entering manual places.  The ability to 'hide' some places from the menu was intended to simplify the Combo menu in this case.  I can accept the single group per type.

Right. If visibility options are available, so that I can hide town or village, and other types that would appear as duplicate Dutch names in the menus, I will finally be able to move on from my own Gramps 3.4.9 fork.

Personally, I see no reason to put any energy in GOV types. GOV is largely European, in the way the the English see it, meaning continental. And in my experience the data for my own country is not very current. Geonames is way better, because it is maintained by a world audience, and not just a German one, with some continental supporters. And IMO, that is a huge difference.


And regarding 'Countries' as a place group;  in my personal use, I like the idea of abbreviating the country and state/province and skipping the anything between that (county etc.) and the bottom level ('populated place') for the charts place titles.  Since my data include some European places, and I often use GOV data, the top level of the hierarchy is usually 'European Union', which is grouped in the GOV data as part of the 'countries' group.  France, for instance, is also grouped as part of the 'countries' group.  So with the current PR, I would write a rule that says "show/abbreviate smallest of countries group, and show/abbreviate largest of 'regions' group", the smallest level being shown by default.  This works well for my data which includes US, Canada and EU places.  If we did not support a 'countries' group, but only a 'regions' group, I'm not sure how I would write this rule without using place specific exception rules.  Even then, we would need a way to say "show the 2nd and 3rd level of the regions group".

From here, I see no point in using EU in any location, and I actually think it's quite silly, because it means that I'll have to exclude the UK and Switzerland from it, which are and have always been European, geography wise. Same for Norway.

I do understand the wish to use abbreviations for states and provinces, and maybe countries too, so if that can be handled by grouping, I like it. I also notice that when I use the Geonames plug-in, abbreviations can be downloaded, wherever available, and we may not need any special rule for those, except to use those when available, regardless of level.

Regards,

Enno




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEPS 045 Place enhancements and Place types

Tim Lyons
Administrator
In reply to this post by prculley
Sorry I haven't replied before or followed the discussion much.

I am very concerned about how place types are exported to GEDCOM. I think it
is essential that exported GEDCOM places can be interpreted correctly by
other programs.

If you have just a blank set of values or a simplified set of types, then it
would (I imagine) be very difficult to create a reasonable GEDCOM
interpretation.

Regards
Tim.



--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-Dev-f1791083.html


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
In reply to this post by prculley
On 21/03/2020 16:18, Paul Culley wrote:

> 1) free form text:  While I understand the apparent simplicity, I
> really think that new users would find an empty entry box a bit less
> intuitive than the current selector with some standard place types. 
> For current users, the need to enter by manually keying in the place
> type would be 'different', and more error prone.  I really think that
> taking away a Gramps 'feature' in the name of simplicity is not a good
> idea, especially since we are doing this whole place enhancements
> thing to add complexity for those users that want to have more
> complete/accurate place descriptions.
>
Our current place type translations are sometimes deliberately
incorrect.  This dates back to when we had a flat data structure with a
fixed list of fields.  So the original Gramps types have different
meanings depending on the language.  A free-form text field would fix
this issue.

Then there is the issue that some English types are difficult to translate.

Also translations are locale specific, not language specific, which is
why pre-defined lists are not a good idea.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
In reply to this post by enno
On 22/03/2020 19:55, Enno Borgsteede wrote:
> Personally, I see no reason to put any energy in GOV types. GOV is
> largely European, in the way the the English see it, meaning
> continental. And in my experience the data for my own country is not
> very current. Geonames is way better, because it is maintained by a
> world audience, and not just a German one, with some continental
> supporters. And IMO, that is a huge difference.

I tend to agree, but we should allow Gramps to work with external data
sources.



_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
In reply to this post by enno
On 22/03/2020 19:55, Enno Borgsteede wrote:

>>
>> And regarding 'Countries' as a place group;  in my personal use, I
>> like the idea of abbreviating the country and state/province and
>> skipping the anything between that (county etc.) and the bottom level
>> ('populated place') for the charts place titles.  Since my data
>> include some European places, and I often use GOV data, the top level
>> of the hierarchy is usually 'European Union', which is grouped in the
>> GOV data as part of the 'countries' group.  France, for instance, is
>> also grouped as part of the 'countries' group.  So with the current
>> PR, I would write a rule that says "show/abbreviate smallest of
>> countries group, and show/abbreviate largest of 'regions' group", the
>> smallest level being shown by default.  This works well for my data
>> which includes US, Canada and EU places.  If we did not support a
>> 'countries' group, but only a 'regions' group, I'm not sure how I
>> would write this rule without using place specific exception rules. 
>> Even then, we would need a way to say "show the 2nd and 3rd level of
>> the regions group".
>
> From here, I see no point in using EU in any location, and I actually
> think it's quite silly, because it means that I'll have to exclude the
> UK and Switzerland from it, which are and have always been European,
> geography wise. Same for Norway.
>
> I do understand the wish to use abbreviations for states and
> provinces, and maybe countries too, so if that can be handled by
> grouping, I like it. I also notice that when I use the Geonames
> plug-in, abbreviations can be downloaded, wherever available, and we
> may not need any special rule for those, except to use those when
> available, regardless of level.
>
This is an interesting example.

The EU is not a country.  It is an economic and political union. So
putting it in a countries group seems wrong, but it is clearly a region.

Having said that, there is nothing to prevent a user defining "country",
"union" or anything else as a custom group.

Being able to defined a formatting rule such as "hide level 2 regions"
seems like a good idea.  This would equate to hiding GeoNames "ADM2"
codes, but in Gramps the level would be determined from the hierarchy.

We should aim to allow users to format places at group level alone.  In
fact, think that many users will prefer to just set a group and not a type.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

Dave Scheipers
On Thu, Apr 2, 2020 at 1:00 PM Nick Hall wrote:
>
> We should aim to allow users to format places at group level alone.  In
> fact, think that many users will prefer to just set a group and not a type.
>

While investigating and seeing what the new place enhancements were
doing, the only formatting I envisioned would be done by specific
place types and not by group. This is especially true where I see most
rules will be done under specific countries.

This may be affected by location bias. Being in the US, I do not see
myself making formatting rules for any other country beyond "Number
Street". ie, I would not apply abbreviations to English counties.
Users outside the US may have other formatting needs where a majority
of their locations are naturally in their home country.

In short, please retain place formatting based upon either Type or Group

Dave


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
On 02/04/2020 20:30, Dave Scheipers wrote:
> In short, please retain place formatting based upon either Type or Group

Yes.  Place formatting should be possible by group, type or a
combination of both.

Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
In reply to this post by Tim Lyons
On 23/03/2020 16:32, Tim Lyons wrote:
> Sorry I haven't replied before or followed the discussion much.
>
> I am very concerned about how place types are exported to GEDCOM. I think it
> is essential that exported GEDCOM places can be interpreted correctly by
> other programs.
>
> If you have just a blank set of values or a simplified set of types, then it
> would (I imagine) be very difficult to create a reasonable GEDCOM
> interpretation.

The GEDCOM for place types in most common usage seems to be the address
tags:  ADR1, ADR2, ADR3, CITY, STAE and CTRY.  There is also the
PLAC.FORM tag which is less widely used.

The address tags can be assigned by the place group alone, even if the
place type list is left empty.

CTRY and STAE are simply the top level and second level places with the
group set to "Region".  These correspond to the Geonames ADM0 and ADM1
codes.

CITY is a place with the group set to "Settlement".  It could also
include towns and villages.

The ADR fields would be populated from places with the group set to
"Locality".

The PLAC.FORM tag needs to be populated from the place type list.  It is
just a list of strings so free-form text is not a problem here.

For full support of time-dependent place types we would need to use
GEDCOM-L.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

Per Starbäck
In reply to this post by enno
> 1) free form text:  While I understand the apparent simplicity, I really think that new users would find an empty entry box a bit less intuitive than the current selector with some standard place types.  For current users, the need to enter by manually keying in the place type would be 'different', and more error prone.  I really think that taking away a Gramps 'feature' in the name of simplicity is not a good idea, especially since we are doing this whole place enhancements thing to add complexity for those users that want to have more complete/accurate place descriptions.
>
> I agree. Predefined place types are helpful, as long as they fit in the user's mind, and are available for the proper locale.

I absolutely agree. I think that each locale probably has a few very
obvious categories that "everyone" would want, and I'm afraid that the
initial impression of Gramps will not be as good if it seems that
these important concepts is something that Gramps doesn't know about
and you have to define them yourself. In Swedish genealogy the Parish
is one of those. With a state church which handled the population
registration (even for non-members after that became possible) for a
long time almost everything is divided according to the same parishes.

Nick Hall wrote:
> Our current place type translations are sometimes deliberately
> incorrect.  This dates back to when we had a flat data structure with a
> fixed list of fields.  So the original Gramps types have different
> meanings depending on the language.

I guess that's it's also often hard to say what *is* correct.
Different locales have different divisions and it's not evident how to
map them against each other.
I'll take Sweden as example since that's what I know best. One
division of Sweden is in "landskap" and one is in "län". "Landskap" is
normally translated into "province" in English, and "län" is normally
translated into "counties".
https://en.wikipedia.org/wiki/Provinces_of_Sweden
https://en.wikipedia.org/wiki/Counties_of_Sweden

In Gramps "län/delstat" is used for "state" and "landskap" is used for
"county"! That could be an example of what you meant by deliberately
incorrect translations.

What I would want is a Swedish locale package which defined these
categories. Everyone who started Gramps with a Swedish locale would
get these (and some others) automatically, but even otherwise you
could load it explicitly to get access to them. So for example someone
from USA with Swedish ancestry would load that and then have a place
category "province" (or maybe "Swedish province"?) for a "landskap".
That is these categories could have names in several languages,
because the language of the interface doesn't have to be the same as
the locale of the places being handled. If there is no name for that
category in the language for the Gramps interface just show the
original/default in that add-on, for example Swedish in the Swedish
add-on.
Each definition in such a locale package should also have info on what
GEDCOM category it should be mapped to on exports.

This way we don't have to handle US states and Swedish län's as the
same kind of entity just to get somewhere convenient to put a "län".
The Swedish translation of "state" in Gramps would not include "län"
but that would be its own type never encountered by someone mostly
handling Swiss cantons in their work, etc. I guess that means I'm pro
these free categories, but only if in practice there are locale packs
that give even new users back at least what we already had.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
On 07/04/2020 20:15, Per Starbäck wrote:

> What I would want is a Swedish locale package which defined these
> categories. Everyone who started Gramps with a Swedish locale would
> get these (and some others) automatically, but even otherwise you
> could load it explicitly to get access to them. So for example someone
> from USA with Swedish ancestry would load that and then have a place
> category "province" (or maybe "Swedish province"?) for a "landskap".
> That is these categories could have names in several languages,
> because the language of the interface doesn't have to be the same as
> the locale of the places being handled. If there is no name for that
> category in the language for the Gramps interface just show the
> original/default in that add-on, for example Swedish in the Swedish
> add-on.
> Each definition in such a locale package should also have info on what
> GEDCOM category it should be mapped to on exports.
>
> This way we don't have to handle US states and Swedish län's as the
> same kind of entity just to get somewhere convenient to put a "län".
> The Swedish translation of "state" in Gramps would not include "län"
> but that would be its own type never encountered by someone mostly
> handling Swiss cantons in their work, etc. I guess that means I'm pro
> these free categories, but only if in practice there are locale packs
> that give even new users back at least what we already had.

You appear to understand the problem and have the basis for a solution. 
The idea of locale packs using the plugin system seems like a good approach.

The plugin could contain a simple list of definitions.  For example:

[
   (_('se|Province'), 'Landskap', PlaceGroup.REGION),
   (_('se|County'), 'Län', PlaceGroup.REGION)
]

When viewing a list of Swedish place types, I would like to see the
Swedish alongside the English translation.  e.g. "Province (Landskap)".

The translation context is necessary so that "gb|County" could be
translated differently from "us|County".

We could add the GEDCOM mapping to the definition, but it may not be
necessary.  It can be determined from the place group and hierarchy as I
outlined in a previous post.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

Dave Scheipers
Would the country's place plugin list be initially installed based
upon the Translation(s) selected at install?

And then if a user finds the need to add the list from another
country, activate the plugin for that country?

Would this prevent Enno from seeing multiply instances of "Dorp"?

On Tue, Apr 7, 2020 at 5:16 PM Nick Hall via Gramps-devel
<[hidden email]> wrote:

>
> On 07/04/2020 20:15, Per Starbäck wrote:
> > What I would want is a Swedish locale package which defined these
> > categories. Everyone who started Gramps with a Swedish locale would
> > get these (and some others) automatically, but even otherwise you
> > could load it explicitly to get access to them. So for example someone
> > from USA with Swedish ancestry would load that and then have a place
> > category "province" (or maybe "Swedish province"?) for a "landskap".
> > That is these categories could have names in several languages,
> > because the language of the interface doesn't have to be the same as
> > the locale of the places being handled. If there is no name for that
> > category in the language for the Gramps interface just show the
> > original/default in that add-on, for example Swedish in the Swedish
> > add-on.
> > Each definition in such a locale package should also have info on what
> > GEDCOM category it should be mapped to on exports.
> >
> > This way we don't have to handle US states and Swedish län's as the
> > same kind of entity just to get somewhere convenient to put a "län".
> > The Swedish translation of "state" in Gramps would not include "län"
> > but that would be its own type never encountered by someone mostly
> > handling Swiss cantons in their work, etc. I guess that means I'm pro
> > these free categories, but only if in practice there are locale packs
> > that give even new users back at least what we already had.
>
> You appear to understand the problem and have the basis for a solution.
> The idea of locale packs using the plugin system seems like a good approach.
>
> The plugin could contain a simple list of definitions.  For example:
>
> [
>    (_('se|Province'), 'Landskap', PlaceGroup.REGION),
>    (_('se|County'), 'Län', PlaceGroup.REGION)
> ]
>
> When viewing a list of Swedish place types, I would like to see the
> Swedish alongside the English translation.  e.g. "Province (Landskap)".
>
> The translation context is necessary so that "gb|County" could be
> translated differently from "us|County".
>
> We could add the GEDCOM mapping to the definition, but it may not be
> necessary.  It can be determined from the place group and hierarchy as I
> outlined in a previous post.
>
>
> Nick.
>
>
>
>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

GRAMPS - Dev mailing list
On 07/04/2020 23:18, Dave Scheipers wrote:
> Would the country's place plugin list be initially installed based
> upon the Translation(s) selected at install?
My suggestion would be to take the default fro the locale.  So if my
locale was 'en_GB.utf8', then I would get the 'gb' pack by default.
>
> And then if a user finds the need to add the list from another
> country, activate the plugin for that country?
Yes.
>
> Would this prevent Enno from seeing multiply instances of "Dorp"?

Yes and No.  By default Enno would get the 'nl' pack which wouldn't
contain duplicates.  However, if he installed the 'gb' pack then he
would also see "Dorp (Town)" and "Dorp (City)" entries for Great Britain.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: GEPS 045 Place enhancements and Place types

enno
Op 08-04-2020 om 00:41 schreef Nick Hall via Gramps-devel:
On 07/04/2020 23:18, Dave Scheipers wrote:
Would this prevent Enno from seeing multiply instances of "Dorp"?

Yes and No.  By default Enno would get the 'nl' pack which wouldn't contain duplicates.  However, if he installed the 'gb' pack then he would also see "Dorp (Town)" and "Dorp (City)" entries for Great Britain.

Well, that'll be ok if you replace Dorp with Stad. A Dorp is a Village, and I currently live in one. But 50 years ago, I lived in a City of size 5000.

In The Netherlands we often use the word Plaats as a neutral form for a registered populated place. With that, we can avoid thinking about Dorp or Stad, and the word is also part of Woonplaats, which translates to Domicile, or Residence.

In this context, with registered, I mean that it can be used in an official document, like as a place of birth.

Regards,

Enno




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel