Further place enhancements

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

Further place enhancements

Nick Hall
Dear Users,

On the 7th Feb I asked you consider some possible place enhancements. 
After receiving your feedback, I decided to approve all six proposals
and they have now been coded.  Thanks to Paul Culley for this work.

However, the development has progressed further than I expected. Paul
has written two extra features:

1.  Expanded the number of place types from 18 to 266, aligning them
with the GOV database.

2.  Enhanced the place format editor, adding new features and removing
the existing format string.

Both of these move Gramps in the right direction, but are challenging
for user interface design.

As you were not asked for your feedback on 7th Feb, and as I don't think
that a good design has yet been achieved, I am asking you again for your
opinions on these two features.

You can see a picture of the new place format editor in the pull request
here:

https://github.com/gramps-project/gramps/pull/806

Unfortunately, in order to see the new place type menu you will need to
run the code.  Maybe some power users out there are willing to do this. 
We may possibly also get some screenshots.

Thanks again for your help.


Regards,


Nick.



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

Re: Further place enhancements

Nick Hall
On 27/03/2019 19:09, Nick Hall wrote:
> We may possibly also get some screenshots.

I have created a wiki page with screenshots here:

https://gramps-project.org/wiki/index.php/Place_Changes


Nick.




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

Re: Further place enhancements

adrian.davey
Nick, it is not [yet] clear from the screenshots exactly what mix of
changes is proposed to be implemented here.

Is the place "Title" now omitted altogether from the editor? [Presumably
with the existing preferenceremoved allowing users to turn OFF "Enable
automatic place title generation"?]

Where & how will place abbreviations be entered? When will we get to see
what is proposed as to how a user can influence when & where an
abbreviation is used?

Can _different_ abbreviations be be set up for different [gramps]
_purposes_? For instance, gramps would in my opinion be much more
functional if a user could set which abbreviation they wish to appear on
charts, compared with in text or web reports.

When will we get to see what is proposed to be the options for
configuring place titles with the expanded set of types?

Adrian Davey


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

Re: Further place enhancements

link
Will the tool allow us to add in custom places?   I was thinking about the discussions we’ve had regarding ships.   And how that could fit under transportation.  


Doug

> On Mar 27, 2019, at 4:16 PM, Adrian Davey <[hidden email]> wrote:
>
> Nick, it is not [yet] clear from the screenshots exactly what mix of changes is proposed to be implemented here.
>
> Is the place "Title" now omitted altogether from the editor? [Presumably with the existing preferenceremoved allowing users to turn OFF "Enable automatic place title generation"?]
>
> Where & how will place abbreviations be entered? When will we get to see what is proposed as to how a user can influence when & where an abbreviation is used?
>
> Can _different_ abbreviations be be set up for different [gramps] _purposes_? For instance, gramps would in my opinion be much more functional if a user could set which abbreviation they wish to appear on charts, compared with in text or web reports.
>
> When will we get to see what is proposed to be the options for configuring place titles with the expanded set of types?
>
> Adrian Davey
>
>
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org



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

Re: Further place enhancements

Nick Hall
In reply to this post by adrian.davey
On 27/03/2019 23:16, Adrian Davey wrote:
> Nick, it is not [yet] clear from the screenshots exactly what mix of
> changes is proposed to be implemented here.


The screenshots only show the new place type hierarchy and place format
editor, but I can add more.


>
> Is the place "Title" now omitted altogether from the editor?
> [Presumably with the existing preferenceremoved allowing users to turn
> OFF "Enable automatic place title generation"?]


This is unchanged.  The legacy title field is still available.


>
> Where & how will place abbreviations be entered? When will we get to
> see what is proposed as to how a user can influence when & where an
> abbreviation is used?


I have added screenshots of the updated place name and new place
abbreviation editors.  Their use will be defined in the place format editor.


>
> Can _different_ abbreviations be be set up for different [gramps]
> _purposes_? For instance, gramps would in my opinion be much more
> functional if a user could set which abbreviation they wish to appear
> on charts, compared with in text or web reports.


It looks like the checkboxes need to be changed to drop-down menus to
allow the user to specify an abbreviation type. Otherwise, you could
specify a different abbreviation for different formats, and choose your
report format accordingly.


>
> When will we get to see what is proposed to be the options for
> configuring place titles with the expanded set of types?


There is already a screenshot of the proposed new place format editor.

Thanks for your comments.


Nick.




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

Re: Further place enhancements

brian fitzgerald
In reply to this post by adrian.davey

I think I get the idea, and I appreciate the hard work gone into this, and I understand the notion of a predefined format for how an ideal "authority" would have subdivided their territory into a one dimensional arbitrary ontology is an alluring goal, but in reality all the world is local.

Worse, these territorial boundaries overlap and not in any consistent way. History saw to that!

Each country, over time, has developed a set of hierarchies, civil, administrative, real estate, judicial, electoral , etc and these hierarchies define where and what genealogical records are created, published and preserved. Genealogists, in some future, need to know these models.

I would have to think long and hard about how, for instance, how an Irish context would be made from this proposed model. Note that the Irish context has (predominately) 4 official, sometimes overlapping, parallel hierarchies for a place; County, Barony, District Electoral Division and Civil Parish. These words have unique meaning in an Irish context. They do not translate well.

I would argue for a fifth if the Catholic church would make its records publicly available.

So I think at first glance that guidance in the wiki can educate the users on the prevailing country model, but the users need to be able to re-create that model for their particular family circumstances, language, political reality and political epoch in Gramps.

I am not saying its easy! But it is the next step.

So I propose to allow an offline local mapping to these GOV theoretical hierarchies so genealogists can work with it. Once its done save it to 'settings' and move on with the real work.

Otherwise I really love where this is going.. Can't wait to see how the reports are going to evolve!


On 3/27/19 7:16 PM, Adrian Davey wrote:
Nick, it is not [yet] clear from the screenshots exactly what mix of changes is proposed to be implemented here.

Is the place "Title" now omitted altogether from the editor? [Presumably with the existing preferenceremoved allowing users to turn OFF "Enable automatic place title generation"?]

Where & how will place abbreviations be entered? When will we get to see what is proposed as to how a user can influence when & where an abbreviation is used?

Can _different_ abbreviations be be set up for different [gramps] _purposes_? For instance, gramps would in my opinion be much more functional if a user could set which abbreviation they wish to appear on charts, compared with in text or web reports.

When will we get to see what is proposed to be the options for configuring place titles with the expanded set of types?

Adrian Davey


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


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

Re: Further place enhancements

Nick Hall
In reply to this post by link
On 27/03/2019 23:41, Doug Lingenbrink wrote:
> Will the tool allow us to add in custom places?
Yes.
> I was thinking about the discussions we’ve had regarding ships.   And how that could fit under transportation.

Possible if we wanted to make "Ship" a standard place.


Nick.




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

Re: Further place enhancements

Rich Lakey
In reply to this post by Nick Hall

I have mixed feelings about this huge list. Will it actually slow one down wading through it? I am happy with the list as is and have added a few such as "cemetery". I would rather just add the entries I need. But I don't know that this proposed list will really slow me down much. But it really isn't much effort to add entries a person wants.

Rich

On 3/27/19 6:56 PM, Nick Hall wrote:
On 27/03/2019 23:16, Adrian Davey wrote:
Nick, it is not [yet] clear from the screenshots exactly what mix of changes is proposed to be implemented here.


The screenshots only show the new place type hierarchy and place format editor, but I can add more.



Is the place "Title" now omitted altogether from the editor? [Presumably with the existing preferenceremoved allowing users to turn OFF "Enable automatic place title generation"?]


This is unchanged.  The legacy title field is still available.



Where & how will place abbreviations be entered? When will we get to see what is proposed as to how a user can influence when & where an abbreviation is used?


I have added screenshots of the updated place name and new place abbreviation editors.  Their use will be defined in the place format editor.



Can _different_ abbreviations be be set up for different [gramps] _purposes_? For instance, gramps would in my opinion be much more functional if a user could set which abbreviation they wish to appear on charts, compared with in text or web reports.


It looks like the checkboxes need to be changed to drop-down menus to allow the user to specify an abbreviation type. Otherwise, you could specify a different abbreviation for different formats, and choose your report format accordingly.



When will we get to see what is proposed to be the options for configuring place titles with the expanded set of types?


There is already a screenshot of the proposed new place format editor.

Thanks for your comments.


Nick.




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


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

Re: Further place enhancements

GRAMPS - User mailing list
This does rvince a concern.  Right now it is virtually impossible to remove accidental/unused Custom pop-up menu insertions. (After searching for & removing occurrences, you have to export, then re-import into a fresh Tree.) Will there be a way to prune such lists? 

I also immediately added "Cemetery" to my Place types. It does seem like that should be a Top-Level standard type for Genealogy software. It gets used enough to justify using that limited real-estate. But it doesn't really fit under Civil because the Church & privately owned aren't Civil constructs.

-Brian

On Wed, Mar 27, 2019 at 19:56, Rich Lakey
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org


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

Untitled Download Attachment
Untitled (268 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Further place enhancements

Ron Johnson
In reply to this post by Rich Lakey

Rich,

Tab into the Place field and start typing.  That'll narrow down the choices.

On 3/27/19 7:54 PM, Rich Lakey wrote:

I have mixed feelings about this huge list. Will it actually slow one down wading through it? I am happy with the list as is and have added a few such as "cemetery". I would rather just add the entries I need. But I don't know that this proposed list will really slow me down much. But it really isn't much effort to add entries a person wants.

Rich

On 3/27/19 6:56 PM, Nick Hall wrote:
On 27/03/2019 23:16, Adrian Davey wrote:
Nick, it is not [yet] clear from the screenshots exactly what mix of changes is proposed to be implemented here.


The screenshots only show the new place type hierarchy and place format editor, but I can add more.



Is the place "Title" now omitted altogether from the editor? [Presumably with the existing preferenceremoved allowing users to turn OFF "Enable automatic place title generation"?]


This is unchanged.  The legacy title field is still available.



Where & how will place abbreviations be entered? When will we get to see what is proposed as to how a user can influence when & where an abbreviation is used?


I have added screenshots of the updated place name and new place abbreviation editors.  Their use will be defined in the place format editor.



Can _different_ abbreviations be be set up for different [gramps] _purposes_? For instance, gramps would in my opinion be much more functional if a user could set which abbreviation they wish to appear on charts, compared with in text or web reports.


It looks like the checkboxes need to be changed to drop-down menus to allow the user to specify an abbreviation type. Otherwise, you could specify a different abbreviation for different formats, and choose your report format accordingly.



When will we get to see what is proposed to be the options for configuring place titles with the expanded set of types?


There is already a screenshot of the proposed new place format editor.

Thanks for your comments.


--
Angular momentum makes the world go 'round.


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

Re: Further place enhancements

Reinhard John
In reply to this post by Nick Hall
Hello,

I appreciate the effort that has been made so far.

My two cents:

* The place list in the screenshots contains German and Enlish terms.
If Gramps wants to cover hierarchies from every country (193) in every language Gramps offers (45) the list will be huge...
Key to winning user acceptance is a configurable expanded place type Menu!


* The emphasis of the discussion is on the input of data! What about working with data and data output?
Making all these place types _standard_ place types does only make sense if I can deal with them in _standard_ reports.

Reinhard

P.S.: I use a tag to indicate a cemetery.



> Gesendet: Mittwoch, 27. März 2019 um 23:00 Uhr
> Von: "Nick Hall" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Gramps-users] Further place enhancements
>
> On 27/03/2019 19:09, Nick Hall wrote:
> > We may possibly also get some screenshots.
>
> I have created a wiki page with screenshots here:
>
> https://gramps-project.org/wiki/index.php/Place_Changes
>
>
> Nick.


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

Re: Further place enhancements

GRAMPS - User mailing list



Hi

Like Reinhard I too appreciate on an academic level what has been
achieved and the ambition to develop

However I see the next feature request being can we have Gramps Lite

Modern software configuration post installation is now almost always
concerned with turning off the features you do not want to make it
easier to see/find what you do want.

So on my system GetGov and and all non English language plugins are
hidden because they are of no practical use to me (no insult implied or
intended). So ease of configuration of the system to me far outweighs
the fact that it satisfies all of the standards of all of the countries
in all of the languages.
So along the same line how many Family Historians are also Ham Radio
enthusiasts if the Maidenhead Locator System is devoloped maybe it
should not be anything other than a check box, latitude/longitude or
Maidenhead as a display stored as latitude/longitude in the database for
which conversion there are already I believe software solutions.

I have "cemetery/crematorium" as a place type and I have a list of
unused types which I would hide/delete to make my list manageable after
I have sorted it alphabetically.

Personal preference in place type  do away with all bar "Unknown" in the
list and then have the sub types Administrative, Civil etc this will
will compact the display


Regards
Phil
MLFHS 12583
Dumfries
On 28/03/2019 10:04, Reinhard John wrote:

> Hello,
>
> I appreciate the effort that has been made so far.
>
> My two cents:
>
> * The place list in the screenshots contains German and Enlish terms.
> If Gramps wants to cover hierarchies from every country (193) in every language Gramps offers (45) the list will be huge...
> Key to winning user acceptance is a configurable expanded place type Menu!
>
>
> * The emphasis of the discussion is on the input of data! What about working with data and data output?
> Making all these place types _standard_ place types does only make sense if I can deal with them in _standard_ reports.
>
> Reinhard
>
> P.S.: I use a tag to indicate a cemetery.
>
>
>
>> Gesendet: Mittwoch, 27. März 2019 um 23:00 Uhr
>> Von: "Nick Hall" <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Gramps-users] Further place enhancements
>>
>> On 27/03/2019 19:09, Nick Hall wrote:
>>> We may possibly also get some screenshots.
>>
>> I have created a wiki page with screenshots here:
>>
>> https://gramps-project.org/wiki/index.php/Place_Changes
>>
>>
>> Nick.
>
>
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>


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

Re: Further place enhancements

prculley
A few comments.  So far I'm the one working on the code and have put a lot of thought into this.
The place type list as it is proposed is already a combination of the original Gramps types, the type list from http://gov.genealogy.net/type/list, and a few additional types that are more generic and would work with the GeoNames data.  A very large number of types.  Because the GOV folks are from Germany, there are a lot of central European place types in the list that have local meaning and don't translate well (or at all) into English or other languages.  And there are almost certainly missing types that have local meaning from other parts of the world.

And it is still possible to add additional custom types (and custom hierarchies).  These can make an individual users db seem OK, until he wants to share his work to someone who speaks a different language.  Then the custom types are not automatically translated, and require a lot of work to fix up.

So no matter how large we make the type list, it is unlikely to solve every potential use.

There are times I think that having place types in Gramps at all was a bad idea.

Two ideas have been tossed out to make the list a bit less daunting, neither have yet be coded up;
1) By default, Only show the user the standard (prior) Gramps types in the menus unless he imports data that contains additional types.  Then show him whatever types is in his db.  This would have the advantage that users doing manual places would not see the huge list ever, and those who used GetGOV or 'Place Cleanup' (GeoNames) data would see the types actually in their db.
2) Provide a configuration option in Preferences to allow the user to select those types that he wanted to see/use.  This would be an ideal place to allow a user to remove/edit any 'custom' types he had entered as well.

When it comes to reports and graphs, the use of 'place formats' to limit the length of an enclosed place name, and to select which hierarchy to display seems desirable.  Gramps already has an editor for this, but it should probably be extended in some way.  There is a screenshot of one possible way to do this on the wiki page Nick created for this topic.  While a configuration setup like the screenshot offers a lot more choice than current, it also has some limitations.

One suggestion already made was to allow place (probably country) specific display formats.  My first thought would be that this should be on an exception basis, otherwise users would have a lot of additional items to set up on a place.

What might be helpful is for users to suggest their desires, and possibly their ideas on how to do this.  We are not the only ones who have good ideas.

Enough for now.

Paul Culley

On Thu, Mar 28, 2019 at 6:19 AM phil wharram via Gramps-users <[hidden email]> wrote:



Hi

Like Reinhard I too appreciate on an academic level what has been
achieved and the ambition to develop

However I see the next feature request being can we have Gramps Lite

Modern software configuration post installation is now almost always
concerned with turning off the features you do not want to make it
easier to see/find what you do want.

So on my system GetGov and and all non English language plugins are
hidden because they are of no practical use to me (no insult implied or
intended). So ease of configuration of the system to me far outweighs
the fact that it satisfies all of the standards of all of the countries
in all of the languages.
So along the same line how many Family Historians are also Ham Radio
enthusiasts if the Maidenhead Locator System is devoloped maybe it
should not be anything other than a check box, latitude/longitude or
Maidenhead as a display stored as latitude/longitude in the database for
which conversion there are already I believe software solutions.

I have "cemetery/crematorium" as a place type and I have a list of
unused types which I would hide/delete to make my list manageable after
I have sorted it alphabetically.

Personal preference in place type  do away with all bar "Unknown" in the
list and then have the sub types Administrative, Civil etc this will
will compact the display


Regards
Phil
MLFHS 12583
Dumfries
On 28/03/2019 10:04, Reinhard John wrote:
> Hello,
>
> I appreciate the effort that has been made so far.
>
> My two cents:
>
> * The place list in the screenshots contains German and Enlish terms.
> If Gramps wants to cover hierarchies from every country (193) in every language Gramps offers (45) the list will be huge...
> Key to winning user acceptance is a configurable expanded place type Menu!
>
>
> * The emphasis of the discussion is on the input of data! What about working with data and data output?
> Making all these place types _standard_ place types does only make sense if I can deal with them in _standard_ reports.
>
> Reinhard
>
> P.S.: I use a tag to indicate a cemetery.
>
>
>
>> Gesendet: Mittwoch, 27. März 2019 um 23:00 Uhr
>> Von: "Nick Hall" <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Gramps-users] Further place enhancements
>>
>> On 27/03/2019 19:09, Nick Hall wrote:
>>> We may possibly also get some screenshots.
>>
>> I have created a wiki page with screenshots here:
>>
>> https://gramps-project.org/wiki/index.php/Place_Changes
>>
>>
>> Nick.
>
>
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>


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


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

Re: Further place enhancements

StoltHD
For a lot of users the GOV database is not known and not easy to use because of the language, but its a good concept.

I can still not understand why Gramps need "Standard Types", is it only because of translation?

If sending a database with Custom Types to another person, their is usually an understanding that i.e. Place Names, Types, Persons Names are written in a localized form... 
And isn't that also the most "correct" way to write it?

For me personally, I would be glad for just "Custom Types", and to be able to create the different Place hierarchies as I need them, but it would be great with some templates for the countries I don't know much about to help me out...

It would be great to be able to turn of the 200+ GOV Types if I can't use them...

And maybe instead be able to configure Custom hierarchies for different usage myself, i.e. Administrative, Religious, Geographical and with the sub levels of each, with the types used in the language I chose, I have no problem with typing in a number of Types, as long as I also have the feature of creating my own "Type Hierarchy", and that its saved.
I also really should wish for an easy way to use this Types and the Type Hierarchy between Databases, without the need of exporting and importing an "Empty" Database...
I also wished there was possible to use the Gramps Clipboard for transferring Database Object between Databases.
Or open 2 databases and drag and drop Objects from one DB to another DB, including the whole hierarchy of a place or the family of a person (Something like Legacy familytree have).
I know that's a lot of job, so...

else, I like the screenshots I see... i'm not to afraid of a few extra configuration options as long as the finished setup will give med a lot more functionality and features to register my data in a more historical correct manner (as I see it, and yes, I know there will be a few in the "inner circle" that will behead me again).

Jaran



tor. 28. mar. 2019 kl. 15:02 skrev Paul Culley <[hidden email]>:
A few comments.  So far I'm the one working on the code and have put a lot of thought into this.
The place type list as it is proposed is already a combination of the original Gramps types, the type list from http://gov.genealogy.net/type/list, and a few additional types that are more generic and would work with the GeoNames data.  A very large number of types.  Because the GOV folks are from Germany, there are a lot of central European place types in the list that have local meaning and don't translate well (or at all) into English or other languages.  And there are almost certainly missing types that have local meaning from other parts of the world.

And it is still possible to add additional custom types (and custom hierarchies).  These can make an individual users db seem OK, until he wants to share his work to someone who speaks a different language.  Then the custom types are not automatically translated, and require a lot of work to fix up.

So no matter how large we make the type list, it is unlikely to solve every potential use.

There are times I think that having place types in Gramps at all was a bad idea.

Two ideas have been tossed out to make the list a bit less daunting, neither have yet be coded up;
1) By default, Only show the user the standard (prior) Gramps types in the menus unless he imports data that contains additional types.  Then show him whatever types is in his db.  This would have the advantage that users doing manual places would not see the huge list ever, and those who used GetGOV or 'Place Cleanup' (GeoNames) data would see the types actually in their db.
2) Provide a configuration option in Preferences to allow the user to select those types that he wanted to see/use.  This would be an ideal place to allow a user to remove/edit any 'custom' types he had entered as well.

When it comes to reports and graphs, the use of 'place formats' to limit the length of an enclosed place name, and to select which hierarchy to display seems desirable.  Gramps already has an editor for this, but it should probably be extended in some way.  There is a screenshot of one possible way to do this on the wiki page Nick created for this topic.  While a configuration setup like the screenshot offers a lot more choice than current, it also has some limitations.

One suggestion already made was to allow place (probably country) specific display formats.  My first thought would be that this should be on an exception basis, otherwise users would have a lot of additional items to set up on a place.

What might be helpful is for users to suggest their desires, and possibly their ideas on how to do this.  We are not the only ones who have good ideas.

Enough for now.

Paul Culley

On Thu, Mar 28, 2019 at 6:19 AM phil wharram via Gramps-users <[hidden email]> wrote:



Hi

Like Reinhard I too appreciate on an academic level what has been
achieved and the ambition to develop

However I see the next feature request being can we have Gramps Lite

Modern software configuration post installation is now almost always
concerned with turning off the features you do not want to make it
easier to see/find what you do want.

So on my system GetGov and and all non English language plugins are
hidden because they are of no practical use to me (no insult implied or
intended). So ease of configuration of the system to me far outweighs
the fact that it satisfies all of the standards of all of the countries
in all of the languages.
So along the same line how many Family Historians are also Ham Radio
enthusiasts if the Maidenhead Locator System is devoloped maybe it
should not be anything other than a check box, latitude/longitude or
Maidenhead as a display stored as latitude/longitude in the database for
which conversion there are already I believe software solutions.

I have "cemetery/crematorium" as a place type and I have a list of
unused types which I would hide/delete to make my list manageable after
I have sorted it alphabetically.

Personal preference in place type  do away with all bar "Unknown" in the
list and then have the sub types Administrative, Civil etc this will
will compact the display


Regards
Phil
MLFHS 12583
Dumfries
On 28/03/2019 10:04, Reinhard John wrote:
> Hello,
>
> I appreciate the effort that has been made so far.
>
> My two cents:
>
> * The place list in the screenshots contains German and Enlish terms.
> If Gramps wants to cover hierarchies from every country (193) in every language Gramps offers (45) the list will be huge...
> Key to winning user acceptance is a configurable expanded place type Menu!
>
>
> * The emphasis of the discussion is on the input of data! What about working with data and data output?
> Making all these place types _standard_ place types does only make sense if I can deal with them in _standard_ reports.
>
> Reinhard
>
> P.S.: I use a tag to indicate a cemetery.
>
>
>
>> Gesendet: Mittwoch, 27. März 2019 um 23:00 Uhr
>> Von: "Nick Hall" <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Gramps-users] Further place enhancements
>>
>> On 27/03/2019 19:09, Nick Hall wrote:
>>> We may possibly also get some screenshots.
>>
>> I have created a wiki page with screenshots here:
>>
>> https://gramps-project.org/wiki/index.php/Place_Changes
>>
>>
>> Nick.
>
>
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>


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


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

Re: Further place enhancements

Nick Hall
On 28/03/2019 15:50, StoltHD wrote:
> I can still not understand why Gramps need "Standard Types", is it
> only because of translation?

In the beginning we had a flat structure of:  Country, State, County,
City, Parish, Street.  Locality was added later.  When we changed to a
hierarchical structure these fixed types became standard types. 
Standard types are useful because they contain a code to identify them
and they are translatable.

You need the code to give the data meaning when transferring between
databases.  At the moment all our custom place types have the code 0 (zero).

Otherwise, yes, we could just have custom types with codes.


Nick.





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

Re: Further place enhancements

GRAMPS - User mailing list
In reply to this post by prculley
Paul,

First of all... thanks for the effort adding this expanded functionality and being willing to risk the inevitable slings and arrows that answer new ideas.

It's probably too late for this or requires too touching too many pieces of code.

An item that occurs to me is that computer data entry is typically optimized to the native country. For instance as an American, I've spliced the US into the top level of the Place Tree instead of its correct place enclosed by North America. I also changed the "United States of America" to "USA". 

Otherwise EVERY Place field overflows with the excessive ", United States of America, North America".  In practice, the only time I actually need to see even the "USA" during data entry is if the Country is the lowest enclosed level. (i.e, the person was born/died/immigrated in the US but I haven't determined in which State.) In Charts, every US place showing more than the 2-letter abbreviated State is "clutter" too.

So most form-based systems have a "relative" function for display & data entry. 

Maybe the Preferences where I enter my name as database owner can have a "Home" Place field and this could be used in 2 ways:
1) De-clutter: Any place display for my country would substitute and ellipsis (...) for the Country level & enclosing region from displaying in dialogs.
2) Accelerate Place selection: the Place Tree defaults to centering on my Home 

-Brian

On Thu, Mar 28, 2019 at 9:04, Paul Culley
...
What might be helpful is for users to suggest their desires, and possibly their ideas on how to do this.  We are not the only ones who have good ideas.

Enough for now.

Paul Culley


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

Re: Further place enhancements

GRAMPS - User mailing list
In reply to this post by Reinhard John
Reinhard,

Just as a point of curiosity...

I understand that you're using Tags for Cemeteries.  But what built-in Place Type do you use with them? Locality? Building? ummm... Farm?

For reference, see:
https://www.gramps-project.org/wiki/index.php/Gramps_5.0_Wiki_Manual_-_Categories#All_known_places

-Brian

On Thu, Mar 28, 2019 at 5:06, Reinhard John
Hello,

I appreciate the effort that has been made so far.

My two cents:

* The place list in the screenshots contains German and Enlish terms.
If Gramps wants to cover hierarchies from every country (193) in every language Gramps offers (45) the list will be huge...
Key to winning user acceptance is a configurable expanded place type Menu!


* The emphasis of the discussion is on the input of data! What about working with data and data output?
Making all these place types _standard_ place types does only make sense if I can deal with them in _standard_ reports.

Reinhard

P.S.: I use a tag to indicate a cemetery.



> Gesendet: Mittwoch, 27. März 2019 um 23:00 Uhr

> Von: "Nick Hall" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Gramps-users] Further place enhancements
>
> On 27/03/2019 19:09, Nick Hall wrote:
> > We may possibly also get some screenshots.
>
> I have created a wiki page with screenshots here:
>
> https://gramps-project.org/wiki/index.php/Place_Changes
>
>
> Nick.


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


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

Re: Further place enhancements

Sebastian Schubert
In reply to this post by StoltHD
Hi all,

On 28/03/2019 16:50, StoltHD wrote:
> For me personally, I would be glad for just "Custom Types", and to be
> able to create the different Place hierarchies as I need them, but it
> would be great with some templates for the countries I don't know much
> about to help me out...

I would also be happy to have only Custom types. I also do not really
see the advantage of official translations. Several terms are used in
very different contexts (borough in English, Bezirk[1] in German, ...),
which makes a perfect general translation impossible. In addition,
custom types are not translated at all at the moment so the system is
not really working.

Also, as said before in this thread, I guess most of the people do not
need the types to be translated. However, for those who need it: What do
you think of letting the user add the translation similar to the
different names of places? The user knows exactly which kind if
Borough/Bezirk/etc. is meant... GetGOV could, when getting data, store
some translations if available.

> It would be great to be able to turn of the 200+ GOV Types if I can't
> use them...

I'd also rather start with 0 types than with 200+ types. In my case, I
would like to get it from GOV. In the long run, there could also be
something like a first-run wizard for each data base, where the user
might be offered some hierarchies to choose from.

Personally, I hope to be able to use Gramps the next 50 years and I
assume most of the people use it at least a couple of years. I am not
afraid of complexity if it allows for efficiency (stable connection to
GOV in my case) and longevity.

Thanks for the great work!

Sebastian

[1]
https://en.wikipedia.org/wiki/Bezirk
https://en.wikipedia.org/wiki/Regierungsbezirk


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

Re: Further place enhancements

Reinhard John
In reply to this post by GRAMPS - User mailing list
Hello Brian,
 
it sounds a little bit odd, but I use the place type "Street" for cemeteries.
I want to control the output of places and "Street" is the only place type below "Locality" that can be controlled using formatting codes. <https://www.gramps-project.org/wiki/index.php/Gramps_5.0_Wiki_Manual_-_Reports_-_part_2#Formatting_Places>
 
Therefore I use "Street" for all farms, hospitals, churches, cemeteries. "Street" is my lowest level, I don't use "Building" or "Number".
 
Reinhard
 
 
Gesendet: Freitag, 29. März 2019 um 00:45 Uhr
Von: "Emyoulation--- via Gramps-users" <[hidden email]>
An: "[hidden email]" <[hidden email]>
Betreff: Re: [Gramps-users] Further place enhancements
Reinhard,
 
Just as a point of curiosity...
 
I understand that you're using Tags for Cemeteries.  But what built-in Place Type do you use with them? Locality? Building? ummm... Farm?
 
For reference, see:
 
-Brian
 


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

Re: Further place enhancements

Nick Hall
On 29/03/2019 11:55, Reinhard John wrote:
> I want to control the output of places and "Street" is the only place
> type below "Locality" that can be controlled using formatting codes.
> <https://www.gramps-project.org/wiki/index.php/Gramps_5.0_Wiki_Manual_-_Reports_-_part_2#Formatting_Places>

Very good point.

The formatter only works with the original fixed place types. This
situation will only get worse the more types we have.

One solution would be to update the formatting codes to refer to groups
of types, like Paul Culley has suggested.

So "a1" could mean administrative level 1, for example, "pp" could mean
populated place, and "up" an unpopulated place like a cemetery.


Nick.




_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
123