Developer Support

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

Developer Support

Andreas Schmidt
Hello Gramps developer,

my name is Andreas Schmidt and I'm from Germany. I'm using Gramps as a
normal user now for nearly one year. Due to my education (I'm holding a
master degree in Computer Science/Software Engineering for nearly 10
years now) I'm also very interested in the development of Gramps.
Therefore I started to setup my development environment (Windows
8.1/Eclipse/Python 2.7) and also begun some code digging to get familiar
with the Gramps code base. Regarding my technical background I would say
that I'm able to handle Python and Git without problems and I have also
some good experiences regarding software design/software architecture.
I've also used Mantis BugTracker in some commercial projects and I've
also experiences with CI (Jenkins under Linux for C/C++ Embedded
Software) and also some basic knowledge of the Gerrit Code Review System.

As a first "learning feature" I would like to implement an additional
Date-Information for alternative place names. I came to this idea during
the collection of differnt names for the same place over a period of
nearly 600 years. One of my ancestor lived in a village which changed 9
times it's name over this period in time. And to associate a name to a
certain time it would be helpful to add this info to the alternativ
place name.

As I read on the mailinglist it could be of interest to get more support
of active developers and hopefully I can provide some support to this
project because I think Gramps is a extremly good genealogy tool and
it's open source!!

What are your expectations and requirements regarding development support?

Best regards from Germany
Andreas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

DS Blank
On Fri, Jan 2, 2015 at 1:34 PM, Andreas Schmidt <[hidden email]> wrote:
Hello Gramps developer,

my name is Andreas Schmidt and I'm from Germany. I'm using Gramps as a
normal user now for nearly one year. Due to my education (I'm holding a
master degree in Computer Science/Software Engineering for nearly 10
years now) I'm also very interested in the development of Gramps.
Therefore I started to setup my development environment (Windows
8.1/Eclipse/Python 2.7) and also begun some code digging to get familiar
with the Gramps code base. Regarding my technical background I would say
that I'm able to handle Python and Git without problems and I have also
some good experiences regarding software design/software architecture.
I've also used Mantis BugTracker in some commercial projects and I've
also experiences with CI (Jenkins under Linux for C/C++ Embedded
Software) and also some basic knowledge of the Gerrit Code Review System.

As a first "learning feature" I would like to implement an additional
Date-Information for alternative place names. I came to this idea during
the collection of differnt names for the same place over a period of
nearly 600 years. One of my ancestor lived in a village which changed 9
times it's name over this period in time. And to associate a name to a
certain time it would be helpful to add this info to the alternativ
place name.

As I read on the mailinglist it could be of interest to get more support
of active developers and hopefully I can provide some support to this
project because I think Gramps is a extremly good genealogy tool and
it's open source!!

What are your expectations and requirements regarding development support?

Best regards from Germany
Andreas

Welcome aboard, Andreas!

I think it was just about 10 years ago that I sent that same email :)

Some links on getting started developing:


For big proposed changes, we have a way of proposing and discussing them:


You might also want to "scratch your own itch" by trying your hand at an addon:


Also, fixing bugs is a great way to learn the source:


-Doug

 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Paul Franklin-5
In reply to this post by Andreas Schmidt
I would certainly also eagerly support you becoming one
of the gramps developers.  You easily sound qualified.

Nick is the czar of Place things and I will let him reply
to your suggestion but (insofar as I know) it sounds like
a nice feature to me.

Besides what Doug said, one way features are added
is to file a "feature request" on the (Mantis) bug tracker.
At least for minor ones which don't needs a GEPS,
which (IMHO) I would guess yours is.

Discussion can then happen on that f.r. and proposed
patches can be attached to it, etc.

Of course, all features only ever go into the "master"
branch, never any "maintenance" branch.

And speaking of the bug tracker, should you feel like
reading it, and fixing any bug you care to, of course
that would be appreciated too!  8-)

Again, welcome!

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Nick Hall
In reply to this post by Andreas Schmidt
On 02/01/15 18:34, Andreas Schmidt wrote:
> As a first "learning feature" I would like to implement an additional
> Date-Information for alternative place names. I came to this idea during
> the collection of differnt names for the same place over a period of
> nearly 600 years. One of my ancestor lived in a village which changed 9
> times it's name over this period in time. And to associate a name to a
> certain time it would be helpful to add this info to the alternativ
> place name.
>

Welcome to Gramps development.  We are always looking for new volunteers.

Adding a time-dependency to place names is a good idea and has already
been suggested.  There are actually a few enhancements that I am
considering.

Are you aware of the Gedcom-L standard?

http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag#Location_Records
http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag

I think that all place names should have a date, language code, and
source citations.  We should also add dates and source citations to
place types.

What do you think about adding a type and source citations to place
references?

I am already working on an enhanced place reference editor and place
formatter for the next major release.

Your help would be very much appreciated.

Regards,


Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Andreas Schmidt
In reply to this post by Paul Franklin-5
Hey guys,

first of all I would like to thank you all for the encouraging words and
the tips and hints for the starting points. Regarding the BugTracker
issues: I've just picked the issue #6548 because I see that problem on
my machine also and therefore it was easy to reproduce ;-) I added a
comment with my observation and my proposal. Hope this is the right way.

Thanks and regards,
Andreas

Am 02.01.2015 um 21:27 schrieb Paul Franklin:

> I would certainly also eagerly support you becoming one
> of the gramps developers.  You easily sound qualified.
>
> Nick is the czar of Place things and I will let him reply
> to your suggestion but (insofar as I know) it sounds like
> a nice feature to me.
>
> Besides what Doug said, one way features are added
> is to file a "feature request" on the (Mantis) bug tracker.
> At least for minor ones which don't needs a GEPS,
> which (IMHO) I would guess yours is.
>
> Discussion can then happen on that f.r. and proposed
> patches can be attached to it, etc.
>
> Of course, all features only ever go into the "master"
> branch, never any "maintenance" branch.
>
> And speaking of the bug tracker, should you feel like
> reading it, and fixing any bug you care to, of course
> that would be appreciated too!  8-)
>
> Again, welcome!


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Andreas Schmidt
In reply to this post by Nick Hall
> Are you aware of the Gedcom-L standard?
>
> http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag#Location_Records
> http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag
The Gedcom-L standard was somehow new to me. I know the GEDCOM standard  
http://wiki-de.genealogy.net/GEDCOM_5.5.1 but not the Gedcom-L
extenensions to that.

> I think that all place names should have a date, language code, and
> source citations.
I just went through the description you send me (PLAC tag of Gedcom-L)
and I saw that the extension include your suggested additions to the
place (date, language code, etc.). What I didn't check so far is the way
Gramps is realizing the Gedcom data structure internally. Because one
point for me is the usage of PLAC and @<XREF:_LOC>@ _LOC regarding place
management and place references. Up to now I haven't informed me about
that.
But neverlethess, talking about the abstract data structure of a place
in Gramps, I would agree that there should be a date, language code and
a source citation.

> We should also add dates and source citations to
> place types.
What is your definition of "place type" in that case? Do you mean e.g.
Village, City, District etc..?

> What do you think about adding a type and source citations to place
> references?

What exactly do you mean by "place references"?

Regards,
Andreas

Am 02.01.2015 um 22:17 schrieb Nick Hall:

> On 02/01/15 18:34, Andreas Schmidt wrote:
>> As a first "learning feature" I would like to implement an additional
>> Date-Information for alternative place names. I came to this idea during
>> the collection of differnt names for the same place over a period of
>> nearly 600 years. One of my ancestor lived in a village which changed 9
>> times it's name over this period in time. And to associate a name to a
>> certain time it would be helpful to add this info to the alternativ
>> place name.
>>
> Welcome to Gramps development.  We are always looking for new volunteers.
>
> Adding a time-dependency to place names is a good idea and has already
> been suggested.  There are actually a few enhancements that I am
> considering.
>
> Are you aware of the Gedcom-L standard?
>
> http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag#Location_Records
> http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag
>
> I think that all place names should have a date, language code, and
> source citations.  We should also add dates and source citations to
> place types.
>
> What do you think about adding a type and source citations to place
> references?
>
> I am already working on an enhanced place reference editor and place
> formatter for the next major release.
>
> Your help would be very much appreciated.
>
> Regards,
>
>
> Nick.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Nick Hall
On 03/01/15 11:30, Andreas Schmidt wrote:

>> I think that all place names should have a date, language code, and
>> >source citations.
> I just went through the description you send me (PLAC tag of Gedcom-L)
> and I saw that the extension include your suggested additions to the
> place (date, language code, etc.). What I didn't check so far is the way
> Gramps is realizing the Gedcom data structure internally. Because one
> point for me is the usage of PLAC and @<XREF:_LOC>@ _LOC regarding place
> management and place references. Up to now I haven't informed me about
> that.
> But neverlethess, talking about the abstract data structure of a place
> in Gramps, I would agree that there should be a date, language code and
> a source citation.

Have a look at place.py in the gramps/gen/lib directory.

A place stores a name and a list of alternative names.  Names are just
strings.  What we would need to do is create a PlaceName object,
containing a name, language and a list of source citations.


>> >We should also add dates and source citations to
>> >place types.
> What is your definition of "place type" in that case? Do you mean e.g.
> Village, City, District etc..?

Yes.  Have a look at placetype.py, also in the gramps/gen/lib directory.

Do we want to allow a place type to change over time?  This could be
useful for regions like Prussia for example.

>
>> >What do you think about adding a type and source citations to place
>> >references?
> What exactly do you mean by "place references"?

Place references (see placeref.py) link places in the hierarchy. Each
place contains a list of PlaceRef objects.  In v4.1, they just contain a
link to a Place object and a Date object.

I pointed out Gedcom-L because it has some good design ideas.  We may
also wish to implement Gedcom-L import/export in the future.


Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

Andreas Schmidt
Am 03.01.2015 um 19:51 schrieb Nick Hall:

> On 03/01/15 11:30, Andreas Schmidt wrote:
>>> I think that all place names should have a date, language code, and
>>>> source citations.
>> I just went through the description you send me (PLAC tag of Gedcom-L)
>> and I saw that the extension include your suggested additions to the
>> place (date, language code, etc.). What I didn't check so far is the way
>> Gramps is realizing the Gedcom data structure internally. Because one
>> point for me is the usage of PLAC and @<XREF:_LOC>@ _LOC regarding place
>> management and place references. Up to now I haven't informed me about
>> that.
>> But neverlethess, talking about the abstract data structure of a place
>> in Gramps, I would agree that there should be a date, language code and
>> a source citation.
> Have a look at place.py in the gramps/gen/lib directory.
>
> A place stores a name and a list of alternative names.  Names are just
> strings.  What we would need to do is create a PlaceName object,
> containing a name, language and a list of source citations.
>
Yeah, that was also my first assumption that we need to replace the
simple string list of alternative place names with a list of new
PlaceName objects including the additional attributes we need.

>>>> We should also add dates and source citations to
>>>> place types.
>> What is your definition of "place type" in that case? Do you mean e.g.
>> Village, City, District etc..?
> Yes.  Have a look at placetype.py, also in the gramps/gen/lib directory.
>
> Do we want to allow a place type to change over time?  This could be
> useful for regions like Prussia for example.
I also think this would be useful. Personally I have some situation in
my ancestry data where I would need such a type change over time.


>>>> What do you think about adding a type and source citations to place
>>>> references?
>> What exactly do you mean by "place references"?
> Place references (see placeref.py) link places in the hierarchy. Each
> place contains a list of PlaceRef objects.  In v4.1, they just contain a
> link to a Place object and a Date object.
>
> I pointed out Gedcom-L because it has some good design ideas.  We may
> also wish to implement Gedcom-L import/export in the future.
>
>
> Nick.
>
>
How is your actual planning regarding the extension of the place
handling functionality respectively the place data structure? As I read,
you are still working on a enhanced place reference editor and place
formatter. And we also discussed about the possible extensions of
alternative place names and place types etc. Should we start a design
document (GEPS?) covering all planned/wished features and enhancements
regarding the "Place" or should I just make a proposal for the
alternative place names extension (date, language, source citation) as a
first small step?

Regards,
Andreas



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

enno
Op 04-01-15 om 19:06 schreef Andreas Schmidt:
> How is your actual planning regarding the extension of the place
> handling functionality respectively the place data structure? As I read,
> you are still working on a enhanced place reference editor and place
> formatter. And we also discussed about the possible extensions of
> alternative place names and place types etc. Should we start a design
> document (GEPS?) covering all planned/wished features and enhancements
> regarding the "Place" or should I just make a proposal for the
> alternative place names extension (date, language, source citation) as a
> first small step?
I'm in favor of a design document (GEP), because we may want to think
about place authorities like the ones offered by FamilySearch or the GOV
on genealogy.net:

http://gov.genealogy.net/search/index

I don't know whether you're involved with that site, but I know someone
who is. He mentioned GEDCOM-L on the FHISO list.

regards,

Enno


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Developer Support

jerome
In reply to this post by Andreas Schmidt
Andreas,

Current model should already fit with the cultural or specific search in Germany?
(I am 1/32 german!)

e,g.
https://gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Background

Anyway, extending the model could be great!

Maybe will also avoid the "spaghetti" generated with the current german "place|sources" index?
http://gov.genealogy.net/search/index


Thanks.
Jérôme


--------------------------------------------
En date de : Dim 4.1.15, Andreas Schmidt <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] Developer Support
 À: [hidden email]
 Date: Dimanche 4 janvier 2015, 19h06
 
 Am 03.01.2015 um 19:51
 schrieb Nick Hall:
 > On 03/01/15 11:30,
 Andreas Schmidt wrote:
 >>> I think
 that all place names should have a date, language code,
 and
 >>>> source citations.
 >> I just went through the description
 you send me (PLAC tag of Gedcom-L)
 >>
 and I saw that the extension include your suggested
 additions to the
 >> place (date,
 language code, etc.). What I didn't check so far is the
 way
 >> Gramps is realizing the Gedcom
 data structure internally. Because one
 >> point for me is the usage of PLAC and
 @<XREF:_LOC>@ _LOC regarding place
 >> management and place references. Up to
 now I haven't informed me about
 >>
 that.
 >> But neverlethess, talking
 about the abstract data structure of a place
 >> in Gramps, I would agree that there
 should be a date, language code and
 >>
 a source citation.
 > Have a look at
 place.py in the gramps/gen/lib directory.
 >
 > A place stores a name
 and a list of alternative names.  Names are just
 > strings.  What we would need to do is
 create a PlaceName object,
 > containing a
 name, language and a list of source citations.
 >
 Yeah, that was also my
 first assumption that we need to replace the
 simple string list of alternative place names
 with a list of new
 PlaceName objects
 including the additional attributes we need.
 
 >>>> We should
 also add dates and source citations to
 >>>> place types.
 >> What is your definition of "place
 type" in that case? Do you mean e.g.
 >> Village, City, District etc..?
 > Yes.  Have a look at placetype.py, also
 in the gramps/gen/lib directory.
 >
 > Do we want to allow a place type to change
 over time?  This could be
 > useful for
 regions like Prussia for example.
 I also
 think this would be useful. Personally I have some situation
 in
 my ancestry data where I would need such
 a type change over time.
 
 
 >>>> What do you
 think about adding a type and source citations to place
 >>>> references?
 >> What exactly do you mean by
 "place references"?
 > Place
 references (see placeref.py) link places in the hierarchy.
 Each
 > place contains a list of PlaceRef
 objects.  In v4.1, they just contain a
 >
 link to a Place object and a Date object.
 >
 > I pointed out
 Gedcom-L because it has some good design ideas.  We may
 > also wish to implement Gedcom-L
 import/export in the future.
 >
 >
 > Nick.
 >
 >
 How
 is your actual planning regarding the extension of the place
 
 handling functionality respectively the
 place data structure? As I read,
 you are
 still working on a enhanced place reference editor and place
 
 formatter. And we also discussed about the
 possible extensions of
 alternative place
 names and place types etc. Should we start a design
 document (GEPS?) covering all planned/wished
 features and enhancements
 regarding the
 "Place" or should I just make a proposal for the
 
 alternative place names extension (date,
 language, source citation) as a
 first small
 step?
 
 Regards,
 Andreas
 
 
 
 ------------------------------------------------------------------------------
 Dive into the World of Parallel Programming!
 The Go Parallel Website,
 sponsored by Intel
 and developed in partnership with Slashdot Media, is your
 hub for all things parallel software
 development, from weekly thought
 leadership
 blogs to news, videos, case studies, tutorials and more.
 Take a
 look and join the conversation now.
 http://goparallel.sourceforge.net
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Andreas Schmidt
In reply to this post by enno
Am 04.01.2015 um 20:18 schrieb Enno Borgsteede:

> Op 04-01-15 om 19:06 schreef Andreas Schmidt:
>> How is your actual planning regarding the extension of the place
>> handling functionality respectively the place data structure? As I read,
>> you are still working on a enhanced place reference editor and place
>> formatter. And we also discussed about the possible extensions of
>> alternative place names and place types etc. Should we start a design
>> document (GEPS?) covering all planned/wished features and enhancements
>> regarding the "Place" or should I just make a proposal for the
>> alternative place names extension (date, language, source citation) as a
>> first small step?
> I'm in favor of a design document (GEP), because we may want to think
> about place authorities like the ones offered by FamilySearch or the GOV
> on genealogy.net:
>
> http://gov.genealogy.net/search/index
>
> I don't know whether you're involved with that site, but I know someone
> who is. He mentioned GEDCOM-L on the FHISO list.
>
> regards,
>
> Enno
>

Hello devs,

today I tried to write a first draft of the design document to extend
the alternative place names with additional information. Therefore I
have created a small document based on the GEPS structure (hopyfully ).
Unfortunately I was not able to distribute it over this mailing list due
to the size restrictions. How could I distribute it? At the moment I
have no account for the Wiki (but it is requested ;-) ) For me it is
important to get your feedback about the ideas because this will help me
to get the right mindset faster.

Thanks and regards,
Andreas


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Nick Hall
On 06/01/15 18:09, Andreas Schmidt wrote:
> today I tried to write a first draft of the design document to extend
> the alternative place names with additional information. Therefore I
> have created a small document based on the GEPS structure (hopyfully ).
> Unfortunately I was not able to distribute it over this mailing list due
> to the size restrictions. How could I distribute it? At the moment I
> have no account for the Wiki (but it is requested;-)  ) For me it is
> important to get your feedback about the ideas because this will help me
> to get the right mindset faster.

Andreas,

Thanks for writing the design document.  It is a good starting point.

I suggest that you sign up for a wiki account and create a wiki page.  
You can then post the link on this list.

In the past I just continued to use GEPS006 for enhancements to the
place functionality.

Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Andreas Schmidt
Am 06.01.2015 um 19:44 schrieb Nick Hall:

> On 06/01/15 18:09, Andreas Schmidt wrote:
>> today I tried to write a first draft of the design document to extend
>> the alternative place names with additional information. Therefore I
>> have created a small document based on the GEPS structure (hopyfully ).
>> Unfortunately I was not able to distribute it over this mailing list due
>> to the size restrictions. How could I distribute it? At the moment I
>> have no account for the Wiki (but it is requested;-)  ) For me it is
>> important to get your feedback about the ideas because this will help me
>> to get the right mindset faster.
> Andreas,
>
> Thanks for writing the design document.  It is a good starting point.
>
> I suggest that you sign up for a wiki account and create a wiki page.
> You can then post the link on this list.
>
> In the past I just continued to use GEPS006 for enhancements to the
> place functionality.
>
> Nick.
>
Thanks for approving my wiki account. I added my proposal as a new GEPS
under the page
https://gramps-project.org/wiki/index.php?title=GEPS_036:_Extended_Alternative_Place_Name_Handling

I didn't add this GEPS page to the actual list of GEPS. I wanted to wait
for your feedback before adding it to the list.

Thanks and regards,
Andreas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Nick Hall
On 06/01/15 20:21, Andreas Schmidt wrote:
> Thanks for approving my wiki account. I added my proposal as a new GEPS
> under the page
> https://gramps-project.org/wiki/index.php?title=GEPS_036:_Extended_Alternative_Place_Name_Handling
>
> I didn't add this GEPS page to the actual list of GEPS. I wanted to wait
> for your feedback before adding it to the list.

I think that the primary place name should also be a PlaceName rather
than a string.  Do we still need to keep the primary place name
separate?  It could be just the first element in a list of names.

The PlaceName probably shouldn't contain a PlaceType.  Places can change
place type without changing name.  We could consider enhancing place
types into a list of time-dependent types.

We can keep this part of GEPS 006 rather than creating a new one.


Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Andreas Schmidt
Am 06.01.2015 um 22:19 schrieb Nick Hall:

> On 06/01/15 20:21, Andreas Schmidt wrote:
>> >Thanks for approving my wiki account. I added my proposal as a new GEPS
>> >under the page
>> >https://gramps-project.org/wiki/index.php?title=GEPS_036:_Extended_Alternative_Place_Name_Handling
>> >
>> >I didn't add this GEPS page to the actual list of GEPS. I wanted to wait
>> >for your feedback before adding it to the list.
> I think that the primary place name should also be a PlaceName rather
> than a string.  Do we still need to keep the primary place name
> separate?  It could be just the first element in a list of names.
I had the same idea while drawing the UML diagram. But I had some
thoughts where I saw a drawback using this solution but I can't remeber
that. :-) So I will change the primary place name also to an instance of
PlaceName object. This will lead to a common handling of this
information and makes the design consistent.

> The PlaceName probably shouldn't contain a PlaceType.  Places can change
> place type without changing name.  We could consider enhancing place
> types into a list of time-dependent types.
Hm, in principle I would agree with that. But keeping the PlaceType
together with the name would ease the handling of changing place types
over time. Because in that case it is just a new PlaceName object with
the same name but a different PlaceType. If we extract it, we need to
handle an additional object including all the GUI stuff without gaining
a benefit.
Displaying this information (same place name, different place type) in
the "Alternativ Place Names" table would also be very easy and clearly
presented. Especially the chronological sorting of the place names if at
first the name changes in time, after that, changing the type without
changing the name and last but not least changing back to the first
name. I think it would be not easy to display this if we separate the
informations.

> We can keep this part of GEPS 006 rather than creating a new one.
To be honest, I would prefere a separte GEPS because adding all related
topics to the same GEPS makes is not easy to handle progress information
for the specific feature and it is hard for every reader to pick the
needed information from the document. But if you want to put it into the
GEPS 006, I can do it.

Regards,
Andreas



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

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

> On 06/01/15 20:21, Andreas Schmidt wrote:
>> Thanks for approving my wiki account. I added my proposal as a new GEPS
>> under the page
>> https://gramps-project.org/wiki/index.php?title=GEPS_036:_Extended_Alternative_Place_Name_Handling
>>
>> I didn't add this GEPS page to the actual list of GEPS. I wanted to wait
>> for your feedback before adding it to the list.
> I think that the primary place name should also be a PlaceName rather
> than a string.  Do we still need to keep the primary place name
> separate?  It could be just the first element in a list of names.
Right, that would bring places in line with persons, where we also have
a list of names, of which one happens to be the primary one.
> The PlaceName probably shouldn't contain a PlaceType.  Places can change
> place type without changing name.  We could consider enhancing place
> types into a list of time-dependent types.
I agree. The type belongs to the place object, not the place name, and
the same goes for the date. And in fact, I don't think that a place name
object is needed, just like it's not needed in GEDCOM X:

https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#27-the-placedescription-data-type

In this names refer to the TextValue type, which is a string, and a
language code. This type is also used in the GEDCOM X standard for
person names.

The names in the GEDCOM X definition are fully qualified ones, like the
titles in Gramps, but to me it looks like the place description can be
used in a hierarchy. I say that, because there is a jurisdiction field
that when used can reference another place description. Turn that into a
list, and you got the whole thing covered, right?
> We can keep this part of GEPS 006 rather than creating a new one.
Please do. It might turn into a long page then, but I can live with that.

regards,

Enno


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Andreas Schmidt
Am 07.01.2015 um 20:57 schrieb Enno Borgsteede:
> I agree. The type belongs to the place object, not the place name, and
> the same goes for the date. And in fact, I don't think that a place name
> object is needed, just like it's not needed in GEDCOM X:
>
> https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#27-the-placedescription-data-type
In that case we would double also the names, type, lat, long. etc. for a
change of one attribute over time. That means: Place changes name in
1845, and changes type in 1939 we will have two complete
PlaceDescription objects for that. Right? I think it is not a good idea
to duplicate all these information of a place

Andreas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

enno
Andreas,

> Am 07.01.2015 um 20:57 schrieb Enno Borgsteede:
>> I agree. The type belongs to the place object, not the place name, and
>> the same goes for the date. And in fact, I don't think that a place name
>> object is needed, just like it's not needed in GEDCOM X:
>>
>> https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#27-the-placedescription-data-type
> In that case we would double also the names, type, lat, long. etc. for a
> change of one attribute over time. That means: Place changes name in
> 1845, and changes type in 1939 we will have two complete
> PlaceDescription objects for that. Right? I think it is not a good idea
> to duplicate all these information of a place
Maybe we need to sort some extra things out first:

1. There are alternative names with no clear date attached, like Berlijn
in Dutch, and Berlin in most other languages. Same for Londen (London)
and Parijs (Paris). These alternative names can exist within a single
language too. Like Amsteldam or Amstelredam for Amsterdam. The latter
have been lost over time, but were not changed on some government order
or anything like that.

2. Types and hierarchies can change over time, sometimes combined, but
that doesn't always imply a change in name. This is like a village
becoming a locality in a city, or a country becoming a state.

In my experience, types and hierarchies change more often than names,
which can be quite persistent in the peoples' minds. In a way this means
that I do not agree with the assumption that you made in your plan,
which is that name and date (always) go together. The village where I
live didn't change name when it became part of a larger municipality,
and neither did the other ones that were included then. And at the same
time, I do recognize that some time ago, Posen became Poznan, and that
was a change in name and hierarchy, but maybe not in type.

In other words, I feel like we need to take a step back, and do a proper
investigation and create proper requirements before doing any modeling
of objects, classes, etc.

regards,

Enno


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Bastien Jacquet
Hi all,

As I recently tried to understand the right theoretical way to handle place name hierarchies over time, let me just throw my two cents into the debate :)
I got to understand that there is two view-point: those have a collection of time-indexed maps, and those aiming at evolving space-time maps.
I also discussed with Geoname people, who are tring to add the time-dimension to their http://www.geonames.org/ (see e.g. www.geonames.org/LA/administrative-division-laos.html )

Their current status is:
A/ a "administrative hierarchy" of "political entities" with their polygon-area. Some having time-periods.
B/ a huge bunch of "populated places" which are just a mapping of names to Lat/Long+scale
Note that B are automatically mapped to A by computing in which polygons they fall into.

Main potential problems to keep in mind (according to them) :
1/ Some places moved (town destroyed and rebuilt 2 km further)
2/ The date of some changes might be controversial (think wars, claimed territories, or places like Jerusalem or east-Urkain)
3/ Their might be philosophical problems if you want some time-continuous representation: what's the name change of Prussia after its end? ( Germany? Austria ? ... ). Or: French people disagree on whether the Vichy government governing France during WW2 was the continuation of the French Republic. 
4/ If handling polygon areas, representing the "motion" of its border over time can be hard.

I looked at gov.genealogy.net, they went for the evolving space-time map. They have both the administrative civil hierarchy and the religious one :it seems pretty nice, although mainly German yet (See Paris : http://gov.genealogy.net/item/show/PARRISJN18DV).
It seems that all attributes (type, name, hierarchy, ...) can have time dependency. That seems right but might be overwhelming to our users if we don't query a place authority.

As for Gramps, my understanding is that we primarily want to map Locations (ie. an house or a real Lat/Long on Earth) to a (political/administrative) place names used by human-beings at a certain time in history.
Each (political/administrative) place can also have an alternate name, per language, as for Parijs/Paris/Parigi, or Londen/London/Londres...
In my mind, the last level is ideally a Location (Lat/Long when known), which is stable over time by definition.

I would be fine with having name changes handled the same way as hierarchy changes. It would remove lot of philosophical discussion on deciding if a change is a name-change or a hierarchy-change.
To avoid duplicating the PlaceDescription we could have it as a (special?) Note.
So an official change of name of a political level "OldPlaceName" to "NewPlaceName" (be it city/region or anything) in 1845 would mean that the link between the Location and "OldPlaceName" will have a time-period ending in 1845. Location will have a new "enclosed-by" link to "NewPlaceName" starting in 1845.
"OldPlaceName" and "NewPlaceName" would probably be enclosed by the very same "BiggerPlace".
The case of Amsteldam/Amstelredam/Amsterdam could be handled with overlapping dates (eg. bef 1700:Amsteldam, aft 1600:Amsterdam)

To summarize, I think that time-dependent alternate names are an overkill which will confuse users.
The current Location + time-dependent Place hierarchy is already quite powerful and quite time-consuming to correctly fill without place authority.

To me it also solve most of Geoname claimed problems:
1/ can be ignored, or worked-around with 2 towns for our use.
2/ can be handled by having time-overlapping place inheritance (although I've no idea how to build a place-representing string with a formatter in that case)
3/ and 4/ can be ignored since we just aim at the mapping from Location+Time to an administrative hierarchy. Name changes will imply new places, without direct time-continuity between them.

Or ... we could use gov.genealogy.net and authorize Gramps users to enrich it (or a copy of it). But this is a huge project on its own. :D

Geoname tend to use a "populated place" (with a name) as what I call Location and what Enno call Place (I think).


This whole problem is quite mind twisting to me, so please complain if I am just saying useless or wrong statements.

PS: it seems that geonames is not free enough to be included openstreetmap. No idea what it means to us.

Regards,

Bastien

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: places

Helge.Herz-2
Am 08.01.2015 02:21, schrieb Bastien Jacquet:

> ...
> To summarize, I think that time-dependent alternate names are an
> overkill which will confuse users.
> The current Location + time-dependent Place hierarchy is already quite
> powerful and quite time-consuming to correctly fill without place authority.
>
> To me it also solve most of Geoname claimed problems:
> 1/ can be ignored, or worked-around with 2 towns for our use.
> 2/ can be handled by having time-overlapping place inheritance (although
> I've no idea how to build a place-representing string with a formatter
> in that case)
> 3/ and 4/ can be ignored since we just aim at the mapping from
> Location+Time to an administrative hierarchy. Name changes will imply
> new places, without direct time-continuity between them.
> ...

1+
A second cent to this topic: May be I'm wrong, but for my opinion a more
complex model for places is an own focus of research. I think Gramps is
the tool to manage ancestry relations / genealogy first. Every thing
around should be as simple as possible (!!) and focused on this goal.
- Helge

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12