Re: user defined place format in text reports

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

Re: user defined place format in text reports

Hans Ulrich Frink-2
As zip file was rejected I made a feature request an d attached my files there.[0009967]

cheers
Uli

2017-02-26 21:52 GMT+01:00 Hans Ulrich Frink <[hidden email]>:
Hi devs,
Since new placeformat which has a lot of adventages was introduced there exists a problem in a lot of reports: The displayformat of places cannot be choosen but results in overlong repeating placenames which make report reading difficult. There have been several feature requests related to that problem [0005149],[0009562], [0009730]

Therefore there should be a format that can be choosen by user on runtime.
So I make a proposal that is illustrated in detailed descendent report and can be easily transfered to other reports.
In every report there is a new menue option that allows choosing several formats

"default" - the placeformat choosen in gramps preferences
"first" - the first place
"firstplace" - the first populated place
"country" - the country
"firstplace-country" a combination
"full" -  the total display.place string

there could be other formats as well.
those formats could be included in draw reports as Nick Hall suggested in the end of 2015 with a format string p

What do you think about that proposal? I attached a zip file with the new files.(I hope my mail is not too long to pass the mailing list.
What are the next steps?

cheers 
Uli


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
On 26/02/17 20:52, Hans Ulrich Frink wrote:
> Therefore there should be a format that can be choosen by user on runtime.

Yes.  I think that it would be useful to be able to select a place
format for a report.

> So I make a proposal that is illustrated in detailed descendent report
> and can be easily transfered to other reports.
> In every report there is a new menue option that allows choosing
> several formats
>
> "default" - the placeformat choosen in gramps preferences
> "first" - the first place
> "firstplace" - the first populated place
> "country" - the country
> "firstplace-country" a combination
> "full" -  the total display.place string
>

Consider the following place:

Number:  12
Street:  High Street
Town:  Stratton
County:  Cornwall
Country:  England

The default format could be "12 High Street, Stratton, Cornwall,
England".  The other formats you suggest would be:

first:  "12"
firstplace:  "Stratton"
country: "England"
firstplace-country:  "Stratton, England"

Are any of these really useful.  There is more than one Stratton in
England so the county is necessary to avoid ambiguity.  There is also a
Stratton in the USA.

> there could be other formats as well.
> those formats could be included in draw reports as Nick Hall suggested
> in the end of 2015 with a format string p

I suggested a notation relative to the populated place because we don't
know what custom place types a user may be using.

So "[p:]" could mean all place names after the populated place, which
would result in "Stratton, Cornwall, England" in the example above.

>
> What do you think about that proposal? I attached a zip file with the
> new files.(I hope my mail is not too long to pass the mailing list.
> What are the next steps?
>
Perhaps we need to design a place format editor.  The user could then
select from some pre-defined formats and also define their own.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

paul womack
Nick Hall wrote:
> On 26/02/17 20:52, Hans Ulrich Frink wrote:
>> Therefore there should be a format that can be choosen by user on runtime.

Some information is lost during transcription to the heirarchy,
and cannot be regained by formatting.

If the original FORMATTING itself carries
information, (e.g. field order, spacing, which line
of a multiline address) decompositiion into
fields loses that information.

The only way I can think of to retain it would be custom
types, e.g prenumber and postnumber as
separate categories of number.

Yuck!

  BugBear

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Hans Ulrich Frink-2
In reply to this post by Nick Hall
Hi,

Thanks for your remarks and suggestions.
To your example: in this example format "First" would not be usefull. In my database I often use a so called "Hausname" (which is the name a family is known but which is connected to the locality or farm family lives) as first locality. We could also use a Format "Britisch Adress Format" [ Number, Street, County, Country, Postcode] or "German Adress Format" or "church Format" [ Place, parish].
As I was looking for a short form of display I choose such. In the end the best would be to feave the user the options.

If I could have a wish fullfilled I would like to have a place-format editor. It should be accessible from every report. and for programming new reports in future it should be easily imported. 
It would display all placetypes - custom as well. You would choose from placetype list as many as you want an bring them into a certain order (could be by mouse drag and drop in a double window or as comboboxes).
Later there could be some "words" such as "in", "in the [placetype]" to be selected and placed as well.
There could be an option field to choose if you want date dependent adresses or the most actual found.
After that an example is shown and format is saved for the report and presented as preselect if you restart the report.

Perhaps such an editor could also be used to compose place standard format. But until now I came along well with the existing routine, But the problem arose with reports where place desciptions were too long.

A parser like used in the draw reports gives the user maximum freedom to compose but I found it hard to understand the syntax in the beginning.

I made my changes in the display.(MY)place.py and it works for my purpose. I can add new formats in MYplace.py, Unfortunately I have to add this format in every report. A profund programmer would find a way to make the changes only in MYplace.py and import the whole stuff into the reports.

cheers
Uli

2017-03-01 0:32 GMT+01:00 Nick Hall <[hidden email]>:
On 26/02/17 20:52, Hans Ulrich Frink wrote:
Therefore there should be a format that can be choosen by user on runtime.

Yes.  I think that it would be useful to be able to select a place format for a report.

So I make a proposal that is illustrated in detailed descendent report and can be easily transfered to other reports.
In every report there is a new menue option that allows choosing several formats

"default" - the placeformat choosen in gramps preferences
"first" - the first place
"firstplace" - the first populated place
"country" - the country
"firstplace-country" a combination
"full" -  the total display.place string


Consider the following place:

Number:  12
Street:  High Street
Town:  Stratton
County:  Cornwall
Country:  England

The default format could be "12 High Street, Stratton, Cornwall, England".  The other formats you suggest would be:

first:  "12"
firstplace:  "Stratton"
country: "England"
firstplace-country:  "Stratton, England"

Are any of these really useful.  There is more than one Stratton in England so the county is necessary to avoid ambiguity.  There is also a Stratton in the USA.

there could be other formats as well.
those formats could be included in draw reports as Nick Hall suggested in the end of 2015 with a format string p

I suggested a notation relative to the populated place because we don't know what custom place types a user may be using.

So "[p:]" could mean all place names after the populated place, which would result in "Stratton, Cornwall, England" in the example above.


What do you think about that proposal? I attached a zip file with the new files.(I hope my mail is not too long to pass the mailing list.
What are the next steps?

Perhaps we need to design a place format editor.  The user could then select from some pre-defined formats and also define their own.


Nick.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Hans Ulrich Frink-2
In reply to this post by paul womack
Hi
Thanks for your remarks.
All data storing leads to data reduction. It should be expained what the stored information is used for then the reduction can be made in a useful way.
This leads to the question, if every place information should reflect the language the adress comes from as e.g. a french adress is composed in an other way as eg in english.
My proposal tries to find an easy to use way not of a principal solution.
cheers 
Uli

2017-03-01 10:40 GMT+01:00 paul womack <[hidden email]>:
Nick Hall wrote:
On 26/02/17 20:52, Hans Ulrich Frink wrote:
Therefore there should be a format that can be choosen by user on runtime.

Some information is lost during transcription to the heirarchy,
and cannot be regained by formatting.

If the original FORMATTING itself carries
information, (e.g. field order, spacing, which line
of a multiline address) decompositiion into
fields loses that information.

The only way I can think of to retain it would be custom
types, e.g prenumber and postnumber as
separate categories of number.

Yuck!

 BugBear


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
In reply to this post by Hans Ulrich Frink-2
On 01/03/17 17:05, Hans Ulrich Frink wrote:
> Thanks for your remarks and suggestions.
> To your example: in this example format "First" would not be usefull.
> In my database I often use a so called "Hausname" (which is the name a
> family is known but which is connected to the locality or farm family
> lives) as first locality. We could also use a Format "Britisch Adress
> Format" [ Number, Street, County, Country, Postcode] or "German Adress
> Format" or "church Format" [ Place, parish].
> As I was looking for a short form of display I choose such. In the end
> the best would be to feave the user the options.

Building format strings from place type variables doesn't really work
any more.  Consider the following format string:

"$Number $Street, $City, $County, $Country"

This would work for certain English places, but what happens with a
place that has a Hamlet, Village or Town instead of a City?  Do we add
them all to the format string?  What about building types such as Church
and Hospital, or a site like a Cemetery?  A place title may contain any
of these types.

Now consider a family tree with places in England and USA.  We could add
a State:

"$Number $Street, $City, $County, $State, $Country"

However, we may not wish to include County for places in the USA,
although it may be useful in the hierarchy.  Do we allow an "if"
statement in the format strings?

A list-slice type notation provides a possible solution.  For example
"[p] + [-2:]" could mean the populated places and the two top-level
regions.  These regions would be County and Country in England and State
and Country in the USA.

Not all places may have a populated place.  Someone gave an example of a
sheep station in the Australian outback that was not near any town.

A similar situation could occur for London if we defined the hierarchy
with a District and Borough instead of a City.

Another alternative would be to add a new field to a place to define it
as hidden in a title.

>
> If I could have a wish fullfilled I would like to have a place-format
> editor. It should be accessible from every report. and for programming
> new reports in future it should be easily imported.
> It would display all placetypes - custom as well. You would choose
> from placetype list as many as you want an bring them into a certain
> order (could be by mouse drag and drop in a double window or as
> comboboxes).
> Later there could be some "words" such as "in", "in the [placetype]"
> to be selected and placed as well.
> There could be an option field to choose if you want date dependent
> adresses or the most actual found.
> After that an example is shown and format is saved for the report and
> presented as preselect if you restart the report.

Each report should ideally have a combobox containing a list of place
formats.

>
> Perhaps such an editor could also be used to compose place standard
> format. But until now I came along well with the existing routine, But
> the problem arose with reports where place desciptions were too long.

Yes.  We could select a global place format in the preferences as we do
for names and dates.

>
> A parser like used in the draw reports gives the user maximum freedom
> to compose but I found it hard to understand the syntax in the beginning.
>
> I made my changes in the display.(MY)place.py and it works for my
> purpose. I can add new formats in MYplace.py, Unfortunately I have to
> add this format in every report. A profund programmer would find a way
> to make the changes only in MYplace.py and import the whole stuff into
> the reports.
>
We could add a "format" parameter to the existing place displayer.  A
default of None could indicate that the global format should be used.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

enno
Hello Nick,

> Now consider a family tree with places in England and USA.  We could add
> a State:
>
> "$Number $Street, $City, $County, $State, $Country"
>
> However, we may not wish to include County for places in the USA,
> although it may be useful in the hierarchy.  Do we allow an "if"
> statement in the format strings?
>
> A list-slice type notation provides a possible solution.  For example
> "[p] + [-2:]" could mean the populated places and the two top-level
> regions.  These regions would be County and Country in England and State
> and Country in the USA.
>
> Not all places may have a populated place.  Someone gave an example of a
> sheep station in the Australian outback that was not near any town.
I don't have much experience with 4.2 or master, so forgive me when I
say something silly, but at the moment we don't have built-in
definitions for PPLs, right? Should they be defined by users, or are you
thinking of categorizing village, town and city as PPLs in code?

When I look at the GeoNames database, I see that PPLs are used in quite
a liberal fashion. My town is officially called Driebergen-Rijsenburg,
but both Driebergen and Rijsenburg are also available as PPLs, with
their own locations on the map, which are the center locations of the
villages before they were united to create a new town.

To me, a remote sheep station is much like a hamlet, and on GeoNames,
the hamlets that I know are coded as PPLs. And in my country the word
'kanton' can be used for different sorts of places. I found the word in
the Amsterdam civil registry, where it's like a borough, but I also
found it in a context where it looked more like a municipality, or a
region. And in todays world, kantons still exist as judicial regions,
more or less the size of provinces, like in Switzerland, where they seem
to be a true equivalent of those.

On GeoNames, Dutch provinces and municipalities are ADM1 and 2, and it
looks like counties are ADM2 in both the UK and the US, with states ADM1
in the US, and England ADM1 too, at least today.

Anyway, to me this looks like for some types, there is no direct
translation to an administrative level, but a list-slice can still work,
because in that, you simply work down from the top.


> A similar situation could occur for London if we defined the hierarchy
> with a District and Borough instead of a City.
Probably, yes.

> Another alternative would be to add a new field to a place to define it
> as hidden in a title.
With that, I could leave out the kanton in old Amsterdam.

When I think of formats for my own country, one wish is to have an
option to display the house and apartment numbers behind the street
name. Without that, I have to put the street name and numbers all in the
street field, which by itself is not that bad, because I don't have many
locations in the same street anywhere, so that in practice I don't
really need the extra level, and the current format works quite well.

In those old Amsterdam records, 'kantons' are numbered, so when I only
enter that number there, I'd wish for the Dutch place formatter to
display the word 'kanton' before that number. For Swiss locations
however, I think that it would look quite foolish, so I have no problem
to type "kanton 1" in a field that I sometimes put below the city
Amsterdam, or above a village in the province of Groningen. I then
assume that a foreign cousin can live with the word cousin when I send a
re port.

This leaves me with another wish, which is to hide a lot of types
altogether. Here in The Netherlands, we only have village (dorp) and
city (stad), so I prefer not to see a translation for town, although it
can be handy for those occasions where I don't really know whether a
place was a 'dorp' or a 'stad'. We often use the word 'plaats' instead,
and in my passport, my place of birth, which is a 'dorp' is listed under
the 'geboorteplaats' title, and and that title is also displayed as
'place of birth', which suggests that the 'place' word has that sort of
generic meaning in English too.

I wish to suppress a lot of other types too, probably leaving just the
ones for hamlet and town districts, next to the ones mentioned before.
And in an ideal world, I'd also wish for visible types to change when I
need to enter a location in France, or Germany, or the UK, or the US.,
maybe then showing the foreign names for those types, so that I see
state for US states, Staat for German ones, etc.

Or am I asking way too much right now?

regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
On 05/03/17 13:14, Enno Borgsteede wrote:
Now consider a family tree with places in England and USA.  We could add
a State:

"$Number $Street, $City, $County, $State, $Country"

However, we may not wish to include County for places in the USA,
although it may be useful in the hierarchy.  Do we allow an "if"
statement in the format strings?

A list-slice type notation provides a possible solution.  For example
"[p] + [-2:]" could mean the populated places and the two top-level
regions.  These regions would be County and Country in England and State
and Country in the USA.

Not all places may have a populated place.  Someone gave an example of a
sheep station in the Australian outback that was not near any town.
I don't have much experience with 4.2 or master, so forgive me when I 
say something silly, but at the moment we don't have built-in 
definitions for PPLs, right? Should they be defined by users, or are you 
thinking of categorizing village, town and city as PPLs in code?

Hamlet, Village, Town and City are defined as populated places within the code.


When I look at the GeoNames database, I see that PPLs are used in quite 
a liberal fashion. My town is officially called Driebergen-Rijsenburg, 
but both Driebergen and Rijsenburg are also available as PPLs, with 
their own locations on the map, which are the center locations of the 
villages before they were united to create a new town.

To me, a remote sheep station is much like a hamlet, and on GeoNames, 
the hamlets that I know are coded as PPLs. And in my country the word 
'kanton' can be used for different sorts of places. I found the word in 
the Amsterdam civil registry, where it's like a borough, but I also 
found it in a context where it looked more like a municipality, or a 
region. And in todays world, kantons still exist as judicial regions, 
more or less the size of provinces, like in Switzerland, where they seem 
to be a true equivalent of those.

The sheep station was given as an example of a location without a populated place.


On GeoNames, Dutch provinces and municipalities are ADM1 and 2, and it 
looks like counties are ADM2 in both the UK and the US, with states ADM1 
in the US, and England ADM1 too, at least today.

Anyway, to me this looks like for some types, there is no direct 
translation to an administrative level, but a list-slice can still work, 
because in that, you simply work down from the top.


Administrative hierarchies are not always useful in genealogy.  In the UK, I prefer using historic counties outside of London.


Nick.



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
In reply to this post by enno
On 05/03/17 13:14, Enno Borgsteede wrote:
Another alternative would be to add a new field to a place to define it
as hidden in a title.
With that, I could leave out the kanton in old Amsterdam.

When I think of formats for my own country, one wish is to have an 
option to display the house and apartment numbers behind the street 
name. Without that, I have to put the street name and numbers all in the 
street field, which by itself is not that bad, because I don't have many 
locations in the same street anywhere, so that in practice I don't 
really need the extra level, and the current format works quite well.

Adding an additional address format would be very easy.


In those old Amsterdam records, 'kantons' are numbered, so when I only 
enter that number there, I'd wish for the Dutch place formatter to 
display the word 'kanton' before that number. For Swiss locations 
however, I think that it would look quite foolish, so I have no problem 
to type "kanton 1" in a field that I sometimes put below the city 
Amsterdam, or above a village in the province of Groningen. I then 
assume that a foreign cousin can live with the word cousin when I send a 
re port.

Why not create a place called "Kanton 1" instead of "1"?


This leaves me with another wish, which is to hide a lot of types 
altogether. Here in The Netherlands, we only have village (dorp) and 
city (stad), so I prefer not to see a translation for town, although it 
can be handy for those occasions where I don't really know whether a 
place was a 'dorp' or a 'stad'. We often use the word 'plaats' instead, 
and in my passport, my place of birth, which is a 'dorp' is listed under 
the 'geboorteplaats' title, and and that title is also displayed as 
'place of birth', which suggests that the 'place' word has that sort of 
generic meaning in English too.

I wish to suppress a lot of other types too, probably leaving just the 
ones for hamlet and town districts, next to the ones mentioned before. 
And in an ideal world, I'd also wish for visible types to change when I 
need to enter a location in France, or Germany, or the UK, or the US., 
maybe then showing the foreign names for those types, so that I see 
state for US states, Staat for German ones, etc.

If you don't use a particular place type, it will only appear in the drop-down lists in the place editors.


Or am I asking way too much right now?

We can still consider new functionality for 5.0 that doesn't change the data model.

A quick place entry dialog that creates all the places for a location would be useful.


Nick.



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Fwd: user defined place format in text reports

Hans Ulrich Frink-2
In reply to this post by Nick Hall
Hi Nick,

Yes.  I think that it would be useful to be able to select a place format for a report.

So I make a proposal that is illustrated in detailed descendent report and can be easily transfered to other reports.
In every report there is a new menue option that allows choosing several formats

"default" - the placeformat choosen in gramps preferences
"first" - the first place
"firstplace" - the first populated place
"country" - the country
"firstplace-country" a combination
"full" -  the total display.place string


Consider the following place:

Number:  12
Street:  High Street
Town:  Stratton
County:  Cornwall
Country:  England

The default format could be "12 High Street, Stratton, Cornwall, England".  The other formats you suggest would be:

first:  "12"
firstplace:  "Stratton"
country: "England"
firstplace-country:  "Stratton, England"

Are any of these really useful.  There is more than one Stratton in England so the county is necessary to avoid ambiguity.  There is also a Stratton in the USA.
I would leave this to the selection by the user. Maybe he has only English adresses, so for him "Stratton" would be useful. Other users would choose "Statton, England"

I suggested a notation relative to the populated place because we don't know what custom place types a user may be using.

So "[p:]" could mean all place names after the populated place, which would result in "Stratton, Cornwall, England" in the example above.

This could be a useful notation for ancestor tree. In other reports I would prefer combo boxes with predefined formats, preferable as examples 

What do you think about that proposal? I attached a zip file with the new files.(I hope my mail is not too long to pass the mailing list.
What are the next steps?

Perhaps we need to design a place format editor.  The user could then select from some pre-defined formats and also define their own.

I wrote some reports in python until now. but I dont know how to wirite an editor, especially using gtk routines like treeview... In my report example I included dropdown fields for choosing a format. The big change is that display.place gets an additional parameter "format" this would affect quite a lot of subroutines.

Uli


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: user defined place format in text reports

Nick Hall
On 06/03/17 23:07, Hans Ulrich Frink wrote:
So "[p:]" could mean all place names after the populated place, which would result in "Stratton, Cornwall, England" in the example above.

This could be a useful notation for ancestor tree. In other reports I would prefer combo boxes with predefined formats, preferable as examples

A format editor could allow us to define place formats and give them a name.  The user could then select a format by name from a combobox.

The problem is how we define a format.  As Enno points out, this is not easy.

Nick.



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: user defined place format in text reports

Hans Ulrich Frink-2
In a first step I would present some predefined formats (see above) which can be composed by place types or slices.
In a second step I would include an editor, which perhaps includes the language field from place type to compose a country specific format.
ancestor tree allows selection of types like Street, city etc. by $e p(c s).
Perhaps in the editor it has to be a combination of slices and types.
cheers
Uli


2017-03-07 0:40 GMT+01:00 Nick Hall <[hidden email]>:
On 06/03/17 23:07, Hans Ulrich Frink wrote:
So "[p:]" could mean all place names after the populated place, which would result in "Stratton, Cornwall, England" in the example above.

This could be a useful notation for ancestor tree. In other reports I would prefer combo boxes with predefined formats, preferable as examples

A format editor could allow us to define place formats and give them a name.  The user could then select a format by name from a combobox.

The problem is how we define a format.  As Enno points out, this is not easy.

Nick


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: user defined place format in text reports

Nick Hall
On 07/03/17 00:14, Hans Ulrich Frink wrote:
> In a first step I would present some predefined formats (see above)
> which can be composed by place types or slices.
> In a second step I would include an editor, which perhaps includes the
> language field from place type to compose a country specific format.
> ancestor tree allows selection of types like Street, city etc. by $e
> p(c s).
> Perhaps in the editor it has to be a combination of slices and types.

I have created an experimental place editor in PR 368:

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


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

enno
In reply to this post by Nick Hall
Hello Nick,

> Why not create a place called "Kanton 1" instead of "1"?
That's exactly what I planned. It works good enough, and does not need
translation either.

> If you don't use a particular place type, it will only appear in the
> drop-down lists in the place editors.
And I'd rather not have it there, meaning that when I enter a Dutch
location, I see no more types than needed for a Dutch location, i.e no
counties or states, no towns, etc. etc. Moreover, when I enter an
English one, I would like to see the word county, in English, also for
the US of course, and similar things for German administrative entities,
like Kreis and Land (State).

>
>> Or am I asking way too much right now?
>
> We can still consider new functionality for 5.0 that doesn't change
> the data model.
>
> A quick place entry dialog that creates all the places for a location
> would be useful.
>
Yes indeed, and one further wish would be that it does look-ups, so that
any existing place will be used, instead of being created new. So, if
there is an entry dialog that has room for street, city/town/village,
county/municipality, province/state, and country, i.e. the most used
fields, it would be nice if it does not create entries.

This is where many other programs, and sites, are sort of ahead of
Gramps, because they verify locations against a gazetteer. They all
store them in a comma separated list, and that is what we also get when
importing a GEDCOM file from those.

Most of these programs are English, but I know that the My Heritage
Family Tree Builder does it too, for more than 40 languages.

I think that most of this can be done with the existing data model, or
maybe an external gazetteer, meaning some table outside the tree with
geonames data.

regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
On 02/04/17 19:03, Enno Borgsteede wrote:
If you don't use a particular place type, it will only appear in the 
drop-down lists in the place editors.
And I'd rather not have it there, meaning that when I enter a Dutch 
location, I see no more types than needed for a Dutch location, i.e no 
counties or states, no towns, etc. etc. Moreover, when I enter an 
English one, I would like to see the word county, in English, also for 
the US of course, and similar things for German administrative entities, 
like Kreis and Land (State).

It doesn't really bother me; I just ignore the types that I am not interested in.

Please feel free to create a feature request or submit a patch.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Nick Hall
In reply to this post by enno
On 02/04/17 19:03, Enno Borgsteede wrote:
A quick place entry dialog that creates all the places for a location 
would be useful.

Yes indeed, and one further wish would be that it does look-ups, so that 
any existing place will be used, instead of being created new. So, if 
there is an entry dialog that has room for street, city/town/village, 
county/municipality, province/state, and country, i.e. the most used 
fields, it would be nice if it does not create entries.

This is where many other programs, and sites, are sort of ahead of 
Gramps, because they verify locations against a gazetteer. They all 
store them in a comma separated list, and that is what we also get when 
importing a GEDCOM file from those.

Most of these programs are English, but I know that the My Heritage 
Family Tree Builder does it too, for more than 40 languages.

I think that most of this can be done with the existing data model, or 
maybe an external gazetteer, meaning some table outside the tree with 
geonames data.

There are two feature requests related to this:

8812: Experimental place gazetteer

https://gramps-project.org/bugs/view.php?id=8812

8974: Import place hierarchies from the GOV database

https://gramps-project.org/bugs/view.php?id=8974

We seem to be heading in the direction of the GOV gazetteer.  Gary Griffin and others have been progressing this.  The experimental GetGOV gramplet is now in the third-party addons repository.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Gary Griffin
This post has NOT been accepted by the mailing list yet.
The GetGOV gramplet allows individual places (and the enclosed-by hierarchy) to be easily imported from the GOV gazetteer. This is very useful for places where the enclosed-by structure is time dependent (Europe). It only includes Populated Places and a little church structure. The interface is to enter the city code and the module will import that city and all of its historic enclosed-by structure. US data has no time structure, so if you enter a US city, you get 3 places (city, county, state) in the enclosed-by structure. This is a one city at a time process. This module does use a non-standard ID for all places it creates.

The PlaceCompletion gramplet allows updates (like adding lat/lon) from the GeoNames gazetteer for multiple places which already exist in your Places at the same time (like all places in a specific US state). It has more types of data (like schools, churches, cemeteries) than just Populated Places. The USA granularity is very good but it is limited to a hierarchy of <place - county - state> . GeoNames data  does not, for instance, contain <place - CITY - county - state >, where place is a hospital or cemetery.

I just found the experimental Gazetteer gramplet on this thread and tried it. It worked to import specific places (any type) from GeoNames. It is useful to understand how to write a gramplet for importing from GeoNames.

I am not aware of any other gazetteer besides GOV and GeoNames. Both are useful in their own way. I tend to use GeoNames for US to update lat/lon (where I have already created the place and its structure) and GOV for Europe for importing place with its historic enclosed-by structure.
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Gary Griffin
In reply to this post by Nick Hall
The GetGOV gramplet allows individual places (and the enclosed-by hierarchy) to be easily imported from the GOV gazetteer. This is very useful for places where the enclosed-by structure is time dependent (Europe). It only includes Populated Places and a little church structure. The interface is to enter the city code and the module will import that city and all of its historic enclosed-by structure. US data has no time structure, so if you enter a US city, you get 3 places (city, county, state) in the enclosed-by structure. This is a one city at a time process. This module does use a non-standard ID for all places it creates.

The PlaceCompletion gramplet allows updates (like adding county and lat/lon) from the GeoNames gazetteer for multiple places which already exist in your Places at the same time (like all places in a specific US state). It has more types of data (like schools, churches, cemeteries) than just Populated Places. The USA granularity is very good but it is limited to a hierarchy of <place - county - state> . GeoNames data  does not, for instance, contain <place - CITY - county - state >, where place is a hospital or cemetery.

I just found the experimental Gazetteer gramplet on this thread and tried it. It worked to import specific places (any type) from GeoNames. It is useful to understand how to write a gramplet for importing from GeoNames.

I am not aware of any other gazetteer besides GOV and GeoNames. Both are useful in their own way. I tend to use GeoNames for US to update lat/lon (where I have already created the place and its structure) and GOV for Europe for importing place with its historic enclosed-by structure.  
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

paul womack
Gary Griffin wrote:
> The GetGOV gramplet allows individual places (and the enclosed-by hierarchy)
> to be easily imported from the GOV gazetteer. This is very useful for places
> where the enclosed-by structure is time dependent (Europe). It only includes
> Populated Places and a little church structure. The interface is to enter
> the city code and the module will import that city and all of its historic
> enclosed-by structure. US data has no time structure...

??

In the early days on colonisation, the names and structure changed frequently.

What about Hawaii?

   BugBear

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: user defined place format in text reports

Gary Griffin
I merely meant that the data in the GOV gazetteer does not include any historic (previous hierarchy and names) for US places. Just like there are no Ireland places entered in to the GOV system. If I look for Honolulu, I only see current name and hierarchy (Honolulu County - Hawaii State - USA).

The module will pull everything in the gazetteer about the name you enter. The data available is generous for most of western europe (lots of name changes and enclosed-by changes), less for USA and Australia (seems to be only current name and enclosed-by) and missing for Ireland, Africa, Asia, India.

You can see what is available by using the web interface at http://gov.genealogy.net/search/index . That data would be imported to Gramps.

Gary