place tree view

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

place tree view

Benny Malengier
All,

You will have noted some changes I did in place tree view. I am trying
out some concepts. I don't like the localization at the moment, I'm
not American after all.
So, I'll probably write a new utility

gen/utils/placedefs.py

with things like

CCODE2STR, which uses iso country codes to map to english and
translated strings, eg
{'BE': ['Belgium', _('Belgium')],

CCODE2DIV, which maps a Country code to the country division levels,

{'USA':[LEVEL_STATE, LEVEL_COUNTY]
'BE': [LEVEL_COUNTY ]
}

and then use that in the placetreeview, so here eg for belgium, no
state level is present.

Then we can have descriptions for countries of the levels,
CCODE2DIVLEVEL, which maps country code to the local variant of LEVEL1
and LEVEL2 for a specific country

CCODE2DIVLEVEL
{'default': [_('State'), _('County')],
'USA': [_('State'), _('County')],
'DE': [_('DE|State'), _('DE|District') ],
'BE': [_('Region'), _('Province')]
}

So this means Gramps knows that the USA is divided in States and
counties, Belgium in regions and provinces (but the region is not used
in treeview), and Germany in States (translated as Bundeslander) and
districts.

We could even add some HIST2STR and HIST2DIV and HIST2DIVLEVEL, for
historical places, like DE_962 for the Holy Roman Empire division, but
that is not for now.

Once this is present, we can rework the place editor to a drop down
list of countries, and store the country code in the country field of
the database (but not in gedcom or gramps export), but also that would
not be for 3.2

Benny

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Gerald Britton-2
The only hiccup I see is that the US state of Louisiana has Parishes
instead of Counties, though they are functionally the same.  Oh, then
you have the District of Columbia, which is neither a state nor a
county.  Same sort of thing in Mexico where the Distrito Federal is
neither a state nor a county.

Annoying, isn't it!

On Mon, Jan 11, 2010 at 7:09 AM, Benny Malengier
<[hidden email]> wrote:

> All,
>
> You will have noted some changes I did in place tree view. I am trying
> out some concepts. I don't like the localization at the moment, I'm
> not American after all.
> So, I'll probably write a new utility
>
> gen/utils/placedefs.py
>
> with things like
>
> CCODE2STR, which uses iso country codes to map to english and
> translated strings, eg
> {'BE': ['Belgium', _('Belgium')],
>
> CCODE2DIV, which maps a Country code to the country division levels,
>
> {'USA':[LEVEL_STATE, LEVEL_COUNTY]
> 'BE': [LEVEL_COUNTY ]
> }
>
> and then use that in the placetreeview, so here eg for belgium, no
> state level is present.
>
> Then we can have descriptions for countries of the levels,
> CCODE2DIVLEVEL, which maps country code to the local variant of LEVEL1
> and LEVEL2 for a specific country
>
> CCODE2DIVLEVEL
> {'default': [_('State'), _('County')],
> 'USA': [_('State'), _('County')],
> 'DE': [_('DE|State'), _('DE|District') ],
> 'BE': [_('Region'), _('Province')]
> }
>
> So this means Gramps knows that the USA is divided in States and
> counties, Belgium in regions and provinces (but the region is not used
> in treeview), and Germany in States (translated as Bundeslander) and
> districts.
>
> We could even add some HIST2STR and HIST2DIV and HIST2DIVLEVEL, for
> historical places, like DE_962 for the Holy Roman Empire division, but
> that is not for now.
>
> Once this is present, we can rework the place editor to a drop down
> list of countries, and store the country code in the country field of
> the database (but not in gedcom or gramps export), but also that would
> not be for 3.2
>
> Benny
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



--
Gerald Britton

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Nick Hall-6
The same sort of issues arise with England.

London is within an administrative area call Greater London which is not
actually a county. I don't see this as a problem though.

England needs the following hierarchy:

Country = England
County
City/Town
Locality
Street

For London, I would probably set the county to London and the City to a
London Borough. An alternative would be to set the county to Greater
London, the city to London and the locality to the borough. Although not
strictly speaking correct, the meaning would be obvious.

In the same way I don't see any real problem of putting District of
Columbia into a state field or a Louisiana parish into a county field.

I like the idea of defining the meaning of the place fields on a country
by country basis. I think that even though the data entry side of things
will not be implemented for version 3.2, we need to think about it when
we are designing hierarchies and data storage and mappings.

When we design the data input we need to think carefully about small
countries (such as England) which do not have a 'state' level in the
hierarchy. There are some websites in which a user has to select British
Isles or UK first and then England. This is putting in an extra level
where it is not needed. It is also quite annoying. We should get the
design right for Gramps to avoid this. Other countries such as Jamaica
just have a Country-County-Town hierarchy.

The addition of a Locality field for England is also useful. In the
current version, because the "state" is not used it can be used to store
a locality. We may want to do this differently when we think about an
improved design.

Let me know if I can help in any way.

Regards,


Nick.


Gerald Britton wrote:

> The only hiccup I see is that the US state of Louisiana has Parishes
> instead of Counties, though they are functionally the same.  Oh, then
> you have the District of Columbia, which is neither a state nor a
> county.  Same sort of thing in Mexico where the Distrito Federal is
> neither a state nor a county.
>
> Annoying, isn't it!
>
> On Mon, Jan 11, 2010 at 7:09 AM, Benny Malengier
> <[hidden email]> wrote:
>  
>> All,
>>
>> You will have noted some changes I did in place tree view. I am trying
>> out some concepts. I don't like the localization at the moment, I'm
>> not American after all.
>> So, I'll probably write a new utility
>>
>> gen/utils/placedefs.py
>>
>> with things like
>>
>> CCODE2STR, which uses iso country codes to map to english and
>> translated strings, eg
>> {'BE': ['Belgium', _('Belgium')],
>>
>> CCODE2DIV, which maps a Country code to the country division levels,
>>
>> {'USA':[LEVEL_STATE, LEVEL_COUNTY]
>> 'BE': [LEVEL_COUNTY ]
>> }
>>
>> and then use that in the placetreeview, so here eg for belgium, no
>> state level is present.
>>
>> Then we can have descriptions for countries of the levels,
>> CCODE2DIVLEVEL, which maps country code to the local variant of LEVEL1
>> and LEVEL2 for a specific country
>>
>> CCODE2DIVLEVEL
>> {'default': [_('State'), _('County')],
>> 'USA': [_('State'), _('County')],
>> 'DE': [_('DE|State'), _('DE|District') ],
>> 'BE': [_('Region'), _('Province')]
>> }
>>
>> So this means Gramps knows that the USA is divided in States and
>> counties, Belgium in regions and provinces (but the region is not used
>> in treeview), and Germany in States (translated as Bundeslander) and
>> districts.
>>
>> We could even add some HIST2STR and HIST2DIV and HIST2DIVLEVEL, for
>> historical places, like DE_962 for the Holy Roman Empire division, but
>> that is not for now.
>>
>> Once this is present, we can rework the place editor to a drop down
>> list of countries, and store the country code in the country field of
>> the database (but not in gedcom or gramps export), but also that would
>> not be for 3.2
>>
>> Benny
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>    
>
>
>
>  

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Jay Treacy
In reply to this post by Gerald Britton-2
On Mon, Jan 11, 2010 at 12:27:23PM -0500, Gerald Britton wrote:
> The only hiccup I see is that the US state of Louisiana has Parishes
> instead of Counties, though they are functionally the same.  Oh, then
> you have the District of Columbia, which is neither a state nor a
> county.  Same sort of thing in Mexico where the Distrito Federal is
> neither a state nor a county.

Want more administrative nightmares? How about NYC. Generally, cities
are within a county. In this case, though, NYC is comprised of 5
boroughs each of which are New York State counties. To make things
confusing, some of the county names are not the same as the borough:

Borough        County
------------   --------
Manhattan      New York
The Bronx      Bronx
Brooklyn       Kings
Queens         Queens
Staten Island  Richmond

--
James Treacy
[hidden email]

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Gerald Britton-2
In reply to this post by Nick Hall-6
Thanks Nick.  Other examples of this problem are places near borders
whose country changed (think Poland before and after WWII) at some
time.  locally I have a county (Lennox and Addington) that was once
two counties: The county of Lennox and the county of Addington.
Toronto, where I live, was once in York county.  In 1953, Metropolitan
Toronto was separated from York County.  So depending on the era, my
"place" is in:

Upper Canada, before 1792
York County, 1792-1953
Metro Toronto, 1953 to the present

As you pointed out, just putting an event at this place is not really
precise, since then the reader has to look at the place and compare
the dates to find out which location it really was.


On Mon, Jan 11, 2010 at 5:00 PM, Nick Hall <[hidden email]> wrote:

> The way I handle London is to put "London" as the county and the
> neighbourhood as the town/city.
>
> Your example of Wimbledon is a good one.  Wimbledon was in Surrey until
> 1974, so before then it would be better to put it in Surrey.  London has
> expanded over the years.
>
> I don't think that I would put London in Middlesex,  I can see why you might
> do though.  Prior to 1889, Westminster, now in the centre of London, was in
> Middlesex.   However, I don't think that the City of London was part of
> Middlesex since it was granted a royal charter in the 12th century.
>
> Going back to the Wimbledon example, you could have the main location
> "Wimbledon, London" and an alternative location of "Wimbledon, Surrey" for
> the same place.  It would be nice to be able to attach a location to an
> event and not just a place.  It has been suggested that locations have a
> date range, but this doesn't work in all cases.  Places such as Wimbledon
> were often referred to as in their historic county even after a boundary
> change.  There must be other examples where a place is referred to by
> different names at the same time, for example in countries where more than
> one language is spoken, or just when a place can have more than one name.
>
>
> Nick.
>
> Gerald Britton wrote:
>>
>> At least Louisiana parishes are analogous to counties in the rest of
>> the country.  With D.C, you have a pseudo-state with no counties.  Not
>> a real problem, just inconvenient
>>
>> For London, depending on when in history, it is either in Middlesex or
>> Greater London.  Of course then you have all the satellites that once
>> were their own cities (e.g, Wimbledon IIRC) that are now just
>> neighborhoods in the megacity.
>>
>> I have my place London in Middlesex, primarily because most of my
>> references predate the borough by many decades (or centuries)
>>
>> how do you handle that?
>>
>> On Mon, Jan 11, 2010 at 2:19 PM, Nick Hall <[hidden email]> wrote:
>>
>>>
>>> The same sort of issues arise with England.
>>>
>>> London is within an administrative area call Greater London which is not
>>> actually a county. I don't see this as a problem though.
>>>
>>> England needs the following hierarchy:
>>>
>>> Country = England
>>> County
>>> City/Town
>>> Locality
>>> Street
>>>
>>> For London, I would probably set the county to London and the City to a
>>> London Borough. An alternative would be to set the county to Greater
>>> London,
>>> the city to London and the locality to the borough. Although not strictly
>>> speaking correct, the meaning would be obvious.
>>>
>>> In the same way I don't see any real problem of putting District of
>>> Columbia
>>> into a state field or a Louisiana parish into a county field.
>>>
>>> I like the idea of defining the meaning of the place fields on a country
>>> by
>>> country basis. I think that even though the data entry side of things
>>> will
>>> not be implemented for version 3.2, we need to think about it when we are
>>> designing hierarchies and data storage and mappings.
>>>
>>> When we design the data input we need to think carefully about small
>>> countries (such as England) which do not have a 'state' level in the
>>> hierarchy. There are some websites in which a user has to select British
>>> Isles or UK first and then England. This is putting in an extra level
>>> where
>>> it is not needed. It is also quite annoying. We should get the design
>>> right
>>> for Gramps to avoid this. Other countries such as Jamaica just have a
>>> Country-County-Town hierarchy.
>>>
>>> The addition of a Locality field for England is also useful. In the
>>> current
>>> version, because the "state" is not used it can be used to store a
>>> locality.
>>> We may want to do this differently when we think about an improved
>>> design.
>>>
>>> Let me know if I can help in any way.
>>>
>>> Regards,
>>>
>>>
>>> Nick.
>>>
>>>
>>> Gerald Britton wrote:
>>>
>>>>
>>>> The only hiccup I see is that the US state of Louisiana has Parishes
>>>> instead of Counties, though they are functionally the same.  Oh, then
>>>> you have the District of Columbia, which is neither a state nor a
>>>> county.  Same sort of thing in Mexico where the Distrito Federal is
>>>> neither a state nor a county.
>>>>
>>>> Annoying, isn't it!
>>>>
>>>> On Mon, Jan 11, 2010 at 7:09 AM, Benny Malengier
>>>> <[hidden email]> wrote:
>>>>
>>>>
>>>>>
>>>>> All,
>>>>>
>>>>> You will have noted some changes I did in place tree view. I am trying
>>>>> out some concepts. I don't like the localization at the moment, I'm
>>>>> not American after all.
>>>>> So, I'll probably write a new utility
>>>>>
>>>>> gen/utils/placedefs.py
>>>>>
>>>>> with things like
>>>>>
>>>>> CCODE2STR, which uses iso country codes to map to english and
>>>>> translated strings, eg
>>>>> {'BE': ['Belgium', _('Belgium')],
>>>>>
>>>>> CCODE2DIV, which maps a Country code to the country division levels,
>>>>>
>>>>> {'USA':[LEVEL_STATE, LEVEL_COUNTY]
>>>>> 'BE': [LEVEL_COUNTY ]
>>>>> }
>>>>>
>>>>> and then use that in the placetreeview, so here eg for belgium, no
>>>>> state level is present.
>>>>>
>>>>> Then we can have descriptions for countries of the levels,
>>>>> CCODE2DIVLEVEL, which maps country code to the local variant of LEVEL1
>>>>> and LEVEL2 for a specific country
>>>>>
>>>>> CCODE2DIVLEVEL
>>>>> {'default': [_('State'), _('County')],
>>>>> 'USA': [_('State'), _('County')],
>>>>> 'DE': [_('DE|State'), _('DE|District') ],
>>>>> 'BE': [_('Region'), _('Province')]
>>>>> }
>>>>>
>>>>> So this means Gramps knows that the USA is divided in States and
>>>>> counties, Belgium in regions and provinces (but the region is not used
>>>>> in treeview), and Germany in States (translated as Bundeslander) and
>>>>> districts.
>>>>>
>>>>> We could even add some HIST2STR and HIST2DIV and HIST2DIVLEVEL, for
>>>>> historical places, like DE_962 for the Holy Roman Empire division, but
>>>>> that is not for now.
>>>>>
>>>>> Once this is present, we can rework the place editor to a drop down
>>>>> list of countries, and store the country code in the country field of
>>>>> the database (but not in gedcom or gramps export), but also that would
>>>>> not be for 3.2
>>>>>
>>>>> Benny
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>>> Take advantage of Verizon's best-in-class app development support
>>>>> A streamlined, 14 day to market process makes app distribution fast and
>>>>> easy
>>>>> Join now and get one step closer to millions of Verizon customers
>>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>>> _______________________________________________
>>>>> Gramps-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>



--
Gerald Britton

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Benny Malengier
2010/1/12 Gerald Britton <[hidden email]>:

> Thanks Nick.  Other examples of this problem are places near borders
> whose country changed (think Poland before and after WWII) at some
> time.  locally I have a county (Lennox and Addington) that was once
> two counties: The county of Lennox and the county of Addington.
> Toronto, where I live, was once in York county.  In 1953, Metropolitan
> Toronto was separated from York County.  So depending on the era, my
> "place" is in:
>
> Upper Canada, before 1792
> York County, 1792-1953
> Metro Toronto, 1953 to the present
>

Officially, a place should be one set of lat/lon (middle point of the
region or so), and alternative locations tab should be used to store
historical places, with the present day place the main location.

The idea was to give historical places a data range from ... till ...,
and on events have Gramps use the date of the event to show the place
title in the event place.
Same for other parts of the GUI.

Places are complicated, and Gramps is not about geographical data, but
about getting genealogy information correct. The place name allows one
to write places up so that the use is clear.

So, depending on how much control you want over your places, you can
make a place for each instance as is needed in you citing the sources,
or group places via the alternative place tab.

In the present day, my feeling is that lat/lon makes clear where a
place is, so what remains is knowing how a place was called at the
time a person lived. The easiest is making new places for different
time era's, as lat/lon makes clear they are the same.
The alternative locations tab allows for nicer organization though,
but then the support in Gramps should improve, as indicated above.

The present change is about how the labels for administrative levels
should be called. This also changes over time periods, but that is
less of an issue.

Benny

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Nick Hall-6

Benny Malengier wrote:

> 2010/1/12 Gerald Britton <[hidden email]>:
>  
>> Thanks Nick.  Other examples of this problem are places near borders
>> whose country changed (think Poland before and after WWII) at some
>> time.  locally I have a county (Lennox and Addington) that was once
>> two counties: The county of Lennox and the county of Addington.
>> Toronto, where I live, was once in York county.  In 1953, Metropolitan
>> Toronto was separated from York County.  So depending on the era, my
>> "place" is in:
>>
>> Upper Canada, before 1792
>> York County, 1792-1953
>> Metro Toronto, 1953 to the present
>>
>>    
>
> Officially, a place should be one set of lat/lon (middle point of the
> region or so), and alternative locations tab should be used to store
> historical places, with the present day place the main location.
>
>  

Yes, there should be one place for a physical location.

The locations tab should be used to store alternative names for that
place.  Names for a place can change over time, but there may also be
different names for the same place within the same time span.

> The idea was to give historical places a data range from ... till ...,
> and on events have Gramps use the date of the event to show the place
> title in the event place.
> Same for other parts of the GUI.
>  

This would be good where there is only one name for a place at any given
time but this is often not the case.  It would be good to think of a
general solution to the problem that solves both issues.

It seems to me that the event should not only store the physical place
but also a reference to which location (name) to use.  Where locations
have date ranges, they could be used to intelligently provide a default
based upon the date of the event.

> Places are complicated, and Gramps is not about geographical data, but
> about getting genealogy information correct. The place name allows one
> to write places up so that the use is clear.
>  

I agree.  If we were only interested in geographical details then the
longitude and latitude and a modern place description would probably be
good enough.  For recording genealogical information though, it would be
useful to record the description of the place as shown on a source document.

> So, depending on how much control you want over your places, you can
> make a place for each instance as is needed in you citing the sources,
> or group places via the alternative place tab.
>
>  

Making multiple places for the same physical place is the way it has to
be done at the moment.  (I suppose you could use one place and then
attach a note to point out which location is relevant).

This is a pity because the alternative location mechanism almost meets
the requirements.  Unfortunately, not quite meeting the requirements is
not good enough.

> In the present day, my feeling is that lat/lon makes clear where a
> place is, so what remains is knowing how a place was called at the
> time a person lived.

This should also be the case if the place had more than name on the
event date.  We need to record a reference to the location in addition
to the place.

> The easiest is making new places for different
> time era's, as lat/lon makes clear they are the same.
> The alternative locations tab allows for nicer organization though,
> but then the support in Gramps should improve, as indicated above.
>  

Since we are working on places it seems worth making the effort to get
things right.  Perhaps we can think of what would be required so we
could make any database changes at the start of version 3.3.

Regards,


Nick.

> The present change is about how the labels for administrative levels
> should be called. This also changes over time periods, but that is
> less of an issue.
>
> Benny
>
>
>  

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Gerald Britton-2
Do we need to worry about bilingual locations? e.g. Brugge or Bruges,
Brussels, Bruxelles or Brussel

On Tue, Jan 12, 2010 at 11:57 AM, Nick Hall <[hidden email]> wrote:

>
> Benny Malengier wrote:
>>
>> 2010/1/12 Gerald Britton <[hidden email]>:
>>
>>>
>>> Thanks Nick.  Other examples of this problem are places near borders
>>> whose country changed (think Poland before and after WWII) at some
>>> time.  locally I have a county (Lennox and Addington) that was once
>>> two counties: The county of Lennox and the county of Addington.
>>> Toronto, where I live, was once in York county.  In 1953, Metropolitan
>>> Toronto was separated from York County.  So depending on the era, my
>>> "place" is in:
>>>
>>> Upper Canada, before 1792
>>> York County, 1792-1953
>>> Metro Toronto, 1953 to the present
>>>
>>>
>>
>> Officially, a place should be one set of lat/lon (middle point of the
>> region or so), and alternative locations tab should be used to store
>> historical places, with the present day place the main location.
>>
>>
>
> Yes, there should be one place for a physical location.
>
> The locations tab should be used to store alternative names for that place.
>  Names for a place can change over time, but there may also be different
> names for the same place within the same time span.
>
>> The idea was to give historical places a data range from ... till ...,
>> and on events have Gramps use the date of the event to show the place
>> title in the event place.
>> Same for other parts of the GUI.
>>
>
> This would be good where there is only one name for a place at any given
> time but this is often not the case.  It would be good to think of a general
> solution to the problem that solves both issues.
>
> It seems to me that the event should not only store the physical place but
> also a reference to which location (name) to use.  Where locations have date
> ranges, they could be used to intelligently provide a default based upon the
> date of the event.
>
>> Places are complicated, and Gramps is not about geographical data, but
>> about getting genealogy information correct. The place name allows one
>> to write places up so that the use is clear.
>>
>
> I agree.  If we were only interested in geographical details then the
> longitude and latitude and a modern place description would probably be good
> enough.  For recording genealogical information though, it would be useful
> to record the description of the place as shown on a source document.
>
>> So, depending on how much control you want over your places, you can
>> make a place for each instance as is needed in you citing the sources,
>> or group places via the alternative place tab.
>>
>>
>
> Making multiple places for the same physical place is the way it has to be
> done at the moment.  (I suppose you could use one place and then attach a
> note to point out which location is relevant).
>
> This is a pity because the alternative location mechanism almost meets the
> requirements.  Unfortunately, not quite meeting the requirements is not good
> enough.
>
>> In the present day, my feeling is that lat/lon makes clear where a
>> place is, so what remains is knowing how a place was called at the
>> time a person lived.
>
> This should also be the case if the place had more than name on the event
> date.  We need to record a reference to the location in addition to the
> place.
>
>> The easiest is making new places for different
>> time era's, as lat/lon makes clear they are the same.
>> The alternative locations tab allows for nicer organization though,
>> but then the support in Gramps should improve, as indicated above.
>>
>
> Since we are working on places it seems worth making the effort to get
> things right.  Perhaps we can think of what would be required so we could
> make any database changes at the start of version 3.3.
>
> Regards,
>
>
> Nick.
>
>> The present change is about how the labels for administrative levels
>> should be called. This also changes over time periods, but that is
>> less of an issue.
>>
>> Benny
>>
>>
>>
>



--
Gerald Britton

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Nick Hall-6
Locations in different languages is one example of multiple locations
for a place in the same time span.  I don't have any data like this myself.

Other examples would be multiple names for political reasons.  e.g.
Derry / Londonderry

There could also be multiple names due to variant spellings which may be
important to record.

Nick.

Gerald Britton wrote:

> Do we need to worry about bilingual locations? e.g. Brugge or Bruges,
> Brussels, Bruxelles or Brussel
>
> On Tue, Jan 12, 2010 at 11:57 AM, Nick Hall <[hidden email]> wrote:
>  
>> Benny Malengier wrote:
>>    
>>> 2010/1/12 Gerald Britton <[hidden email]>:
>>>
>>>      
>>>> Thanks Nick.  Other examples of this problem are places near borders
>>>> whose country changed (think Poland before and after WWII) at some
>>>> time.  locally I have a county (Lennox and Addington) that was once
>>>> two counties: The county of Lennox and the county of Addington.
>>>> Toronto, where I live, was once in York county.  In 1953, Metropolitan
>>>> Toronto was separated from York County.  So depending on the era, my
>>>> "place" is in:
>>>>
>>>> Upper Canada, before 1792
>>>> York County, 1792-1953
>>>> Metro Toronto, 1953 to the present
>>>>
>>>>
>>>>        
>>> Officially, a place should be one set of lat/lon (middle point of the
>>> region or so), and alternative locations tab should be used to store
>>> historical places, with the present day place the main location.
>>>
>>>
>>>      
>> Yes, there should be one place for a physical location.
>>
>> The locations tab should be used to store alternative names for that place.
>>  Names for a place can change over time, but there may also be different
>> names for the same place within the same time span.
>>
>>    
>>> The idea was to give historical places a data range from ... till ...,
>>> and on events have Gramps use the date of the event to show the place
>>> title in the event place.
>>> Same for other parts of the GUI.
>>>
>>>      
>> This would be good where there is only one name for a place at any given
>> time but this is often not the case.  It would be good to think of a general
>> solution to the problem that solves both issues.
>>
>> It seems to me that the event should not only store the physical place but
>> also a reference to which location (name) to use.  Where locations have date
>> ranges, they could be used to intelligently provide a default based upon the
>> date of the event.
>>
>>    
>>> Places are complicated, and Gramps is not about geographical data, but
>>> about getting genealogy information correct. The place name allows one
>>> to write places up so that the use is clear.
>>>
>>>      
>> I agree.  If we were only interested in geographical details then the
>> longitude and latitude and a modern place description would probably be good
>> enough.  For recording genealogical information though, it would be useful
>> to record the description of the place as shown on a source document.
>>
>>    
>>> So, depending on how much control you want over your places, you can
>>> make a place for each instance as is needed in you citing the sources,
>>> or group places via the alternative place tab.
>>>
>>>
>>>      
>> Making multiple places for the same physical place is the way it has to be
>> done at the moment.  (I suppose you could use one place and then attach a
>> note to point out which location is relevant).
>>
>> This is a pity because the alternative location mechanism almost meets the
>> requirements.  Unfortunately, not quite meeting the requirements is not good
>> enough.
>>
>>    
>>> In the present day, my feeling is that lat/lon makes clear where a
>>> place is, so what remains is knowing how a place was called at the
>>> time a person lived.
>>>      
>> This should also be the case if the place had more than name on the event
>> date.  We need to record a reference to the location in addition to the
>> place.
>>
>>    
>>> The easiest is making new places for different
>>> time era's, as lat/lon makes clear they are the same.
>>> The alternative locations tab allows for nicer organization though,
>>> but then the support in Gramps should improve, as indicated above.
>>>
>>>      
>> Since we are working on places it seems worth making the effort to get
>> things right.  Perhaps we can think of what would be required so we could
>> make any database changes at the start of version 3.3.
>>
>> Regards,
>>
>>
>> Nick.
>>
>>    
>>> The present change is about how the labels for administrative levels
>>> should be called. This also changes over time periods, but that is
>>> less of an issue.
>>>
>>> Benny
>>>
>>>
>>>
>>>      
>
>
>
>  

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: place tree view

Benny Malengier
In reply to this post by Gerald Britton-2
2010/1/12 Gerald Britton <[hidden email]>:
> Do we need to worry about bilingual locations? e.g. Brugge or Bruges,
> Brussels, Bruxelles or Brussel

Are you trying to get a reaction from me??

Then I would say Brussels is never correct :-)

Benny

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel